Kubernetes monolith

[Enkidu93]

Fixes #922

I've tested this on internal-qa and it seems to be working fine, but I'd like to do a bit more testing.

---

This change is 

[ddaspit]

It seems simple enough. Have we gotten any feedback from LTOps on the CPU and memory limits?

@ddaspit reviewed 9 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Enkidu93).

[Enkidu93]

It seems simple enough. Have we gotten any feedback from LTOps on the CPU and memory limits?

@ddaspit reviewed 9 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Enkidu93).

Still talking to Greg. It looks like memory is the place we should try to use as little as possible. Greg is chill with there being no limits on the CPU resources (which I actually already removed as per his request last month). He has OK'd the values in this PR as a good starting place and says we can monitor it.

[Enkidu93]

Alright, I've tested this now more completely. Here's how I've tested it:

1. Ran a production-copy build on int-qa using recreate_build.py.
2. Confirmed that the build ran successfully and that the db was populated.
3. Migrated the db using the migration commands in the relevant issue.
4. Confirmed that the new db set-up looks correct and that data has been migrated.
5. Deployed the new monolith int-qa and made sure it was healthy.
6. Confirmed that the db still looked correct (still has migrated docs etc.).
7. Made sure I can successfully download a datafile created before the migration.
8. Ran the production build again on the int-qa (now monolith).
9. Confirmed that the new build ran successfully.
10. Confirmed that I can delete engines (created pre and post migration) and consequently the relevant serval and serval.machine documents are deleted.

@ddaspit @pmachapman Anything else you think we should test?

[ddaspit]

This covers everything I can think of.

@ddaspit made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Enkidu93).

[pmachapman]

The only thing I can think of is to verify that files in the volume mounts are still present. The claims look correct for each volume, so they should be all OK.

@pmachapman reviewed 9 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Enkidu93).

[Enkidu93]

@pmachapman, wouldn't that be covered by being able to download a data file that was uploaded pre-monolith? Or am I not understanding?

[pmachapman]

wouldn't that be covered by being able to download a data file that was uploaded pre-monolith? Or am I not understanding?

@Enkidu93 Yes, ignore me!

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.73%. Comparing base (6c222a2) to head (39fff99).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #932   +/-   ##
=======================================
  Coverage   66.73%   66.73%           
=======================================
  Files         372      372           
  Lines       21687    21687           
  Branches     2771     2771           
=======================================
  Hits        14472    14472           
  Misses       6179     6179           
  Partials     1036     1036           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.