-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add -ness checks and refactor migrations #1674
Conversation
e49c674
to
2f1f75b
Compare
@@ -0,0 +1,57 @@ | |||
--- | |||
|
|||
- name: Check for pending migrations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This task ensures that the k8s job is only run if there are new schema changes to be migrated.
And the unique name based on the version and the random hash ensure that there are no conflicts with other k8s jobs from previous migrations.
{{ lookup("template", "../common/templates/labels/version.yaml.j2") | indent(width=4) | trim }} | ||
spec: | ||
template: | ||
spec: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dhageman One thought I had is that we might want to be mindful of cleaning up these migration jobs in case a deployment gets in a bad state and winds up creating them in a loop after the timeout is reached. The job containers are automatically cleaned up after 3600 seconds, which is pretty reasonable.
If we need to, we can adjust this via .spec.ttlSecondsAfterFinished
. Though that is probably a good default to start with since it strikes a nice balance between "not cluttering things" and having logs stick around long enough for debugging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You make an excellent point. There is definitely a balance there.
@dhageman thank you for your time and effort to develop this solution. I think it is robust and will be a good pattern. |
SUMMARY
This PR implements liveness & readiness probes supporting the split web/task container configuration. It also adjusts database migrations to be done in the init container of the task pod.
Addresses #414 & #926
ISSUE TYPE
ADDITIONAL INFORMATION
It should be acknowledged that this is not the first work on implementing these features.