Skip to content

fix: keep pull secrets and sysctls on flag deploy - #637

Merged
scotwells merged 1 commit into
mainfrom
claude/project-thread-fuzean
Nov 11, 2026
Merged

scotwells merged 1 commit into
mainfrom
claude/project-thread-fuzean

Conversation

@scotwells

Copy link
Copy Markdown
Contributor

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

  • The flag path rebuilds the sandbox from scratch with only the container it describes. It now copies imagePullSecrets and sysctls from the stored sandbox when the workload already exists; a new workload is unchanged.
  • No flag to set or remove pull secrets is added here. That can follow if wanted; a manifest deploy still manages them.

Test plan

  • New unit test covers redeploy keeping both fields, a new workload starting empty, and an existing workload with no sandbox
  • Existing deploy command tests pass
  • go vet and gofmt clean on the package
  • After merge, a flag redeploy of a staging workload with a pull secret keeps the secret and its instance becomes Available

Generated by Claude Code

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
@scotwells
scotwells requested a review from a team as a code owner November 11, 2026 14:57
@scotwells scotwells self-assigned this Nov 11, 2026

@kevwilliams kevwilliams left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified the sandbox has only containers, pull secrets and sysctls, so a flag redeploy now carries forward every field it does not set.

@scotwells
scotwells merged commit 596d458 into main Nov 11, 2026
12 checks passed
@scotwells
scotwells deleted the claude/project-thread-fuzean branch November 11, 2026 15:30

@ecv ecv left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flag deploy removes imagePullSecrets from an existing workload

3 participants