Repository navigation
fix: keep pull secrets and sysctls on flag deploy - #637
Merged
Merged
Conversation
A flag deploy rewrites the whole workload spec and built a sandbox with only the flag-described container. Image pull secrets and sysctls set by a manifest were silently dropped, so the next instance of a workload pulling a private image stuck at ImageUnavailable. Key changes: - carry an existing workload's imagePullSecrets and sysctls forward when the flag path rebuilds the sandbox - say so in the deploy help next to the other carried-forward settings - add a unit test for the create, redeploy and no-sandbox cases Fixes #432
kevwilliams
approved these changes
Nov 11, 2026
kevwilliams
left a comment
Contributor
There was a problem hiding this comment.
Verified the sandbox has only containers, pull secrets and sysctls, so a flag redeploy now carries forward every field it does not set.
ecv
approved these changes
Nov 11, 2026
ecv
left a comment
Contributor
There was a problem hiding this comment.
Approve. A flag redeploy now keeps the stored imagePullSecrets and sysctls instead of rebuilding the sandbox without them, and dropping the pull-secret copy fails TestSandboxRuntime. No flag sets either field, so the stored values are copied whole and nothing can conflict.
Follow-ups:
- A flag deploy can no longer remove a pull secret or sysctl, and moving to a public image keeps the old secret. Removal now needs a manifest deploy; say so in the help text.
- The test covers sandboxRuntime but not its call in deployFromFlags, so reverting the call site would still pass.
- Flag deploys still drop other spec fields they do not model, such as spec.template annotations including RestartedAtAnnotation. Same class of bug.
This file contains hidden or 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
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.
Requested by Scot Schuchert-Wells · project thread
Redeploying an existing workload with flags (for example to add an HTTP port) silently removed the image pull secrets a manifest had set, so the next instance of a workload pulling a private image could never start. Kernel parameters (sysctls) set by a manifest were dropped the same way. A flag deploy now keeps both from the existing workload, like it already does for the runtime class, network, environment, mounts and labels. The deploy help now lists them among the settings that carry forward.
Fixes #432
Details
imagePullSecretsandsysctlsfrom the stored sandbox when the workload already exists; a new workload is unchanged.Test plan
go vetandgofmtclean on the packageGenerated by Claude Code