-
Notifications
You must be signed in to change notification settings - Fork 75
increase jobs runner default priority #243
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
base: main
Are you sure you want to change the base?
Conversation
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.
Pull Request Overview
This PR introduces higher default priorities for Retool jobs-runner and backend pods when no global priorityClassName
is specified, aiming to prevent upgrade crash loops by ensuring critical jobs (like database migrations) complete.
- Adds two new
PriorityClass
resources (jobs-runner and backend) inpriorityclass.yaml
- Updates
deployment_jobs.yaml
anddeployment_backend.yaml
to conditionally use the new defaults or the global override - Bumps Helm chart version from 6.6.0 to 6.6.1
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
File | Description |
---|---|
charts/retool/templates/priorityclass.yaml | New PriorityClass definitions for jobs-runner and backend pods |
charts/retool/templates/deployment_jobs.yaml | Conditional templating for jobs-runner priorityClassName |
charts/retool/templates/deployment_backend.yaml | Conditional templating for backend priorityClassName |
charts/retool/Chart.yaml | Helm chart version bump to 6.6.1 |
Comments suppressed due to low confidence (3)
charts/retool/templates/deployment_jobs.yaml:49
- The
priorityClassName
templating logic is duplicated across multiple deployment templates. Consider extracting this into a shared helper (e.g., in_helpers.tpl
) to reduce duplication and simplify future updates.
{{- else }}
charts/retool/templates/deployment_backend.yaml:51
- The same defaulting logic appears here as in
deployment_jobs.yaml
. Extract this into a helper function to keep the chart DRY and easier to maintain.
priorityClassName: {{ printf "%s-backend-priority" (include "retool.fullname" .) | quote }}
charts/retool/templates/priorityclass.yaml:1
- There’s currently no test coverage for rendering these
PriorityClass
resources whenpriorityClassName
is unset. Consider adding a Helm template unit test to ensure this conditional outputs the expected YAML.
{{- if not .Values.priorityClassName }}
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.
nice
@@ -0,0 +1,23 @@ | |||
{{- if not .Values.priorityClassName }} |
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.
worth a comment explaining why we're intentionally deprioritizing backend here
bbd3f36
to
77f003e
Compare
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.
I'd prob add a new field in values to disable this new priorityclass behavior, in case some customer has an env that doesn't support it (conflicts, various internal policies, whatever) or they just don't want it. previously, PriorityClass was strictly opt-in, now we're making it default on (when no priorityClassName specified) or overridable (if priorityClassName is specified) but no way to actually just opt out.
Adding two new default (higher) priority classes to the backend and jobs-runners pods, in order to eliminate crash loops during upgrades due to un-ran jobs (namely db migrations).
Currently, this change will only be applied when the global “priorityClassName” is not set. If it is, these default values will be overridden. In the future, it might be useful to create per-pod PriorityClass overrides in order to enable similar behavior, while still allowing a global priorityClassName.