crc: run migrations in a separate container #2372
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
/retest |
drodowic
force-pushed
the
crc-migrations
branch
from
acdd7d5 to
fc3cfdb
Compare
|
drodowic
changed the title
jctanner
approved these changes
Nov 30, 2024
cutwater
approved these changes
Dec 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is this PR doing:
Moves migrations out of the init container on the API pod to a separate pod
Why:
The recent deployment of crc-2024-11-25 has introduced a lot of post-migration hooks that cause migrations to take at least an hour even if there are no migrations to apply. Since migrations are currently handled in the init container of the API pods this causes the scaling of the API to occur very slowly.
Using a Job or ClowdJobInvocation is not feasible, because the AppSRE tooling reconciles Jobs after other resource types. This is useful when a Job is utilized to run integration tests after a deployment, but makes it impossible for migrations to run in a Job before the other resources roll out.