Helm: worker strategy maxUnavailable value is ignored by template
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- helm, kubernetes
- Domain
- devops
Research direction
Start with templates/worker/worker-deploy.yaml and compare its maxUnavailable handling with maxSurge and the worker.strategy settings in values.yaml. Run helm template with worker.strategy.maxUnavailable set and unset, then run scripts/install-dry-run.sh. Done means the configured value renders when set and the existing default remains otherwise.
Written by the indexing model from the issue text.
Description
Summary
openstudio-server/templates/worker/worker-deploy.yaml hardcodes maxUnavailable: 1 even though values.yaml exposes worker.strategy.maxUnavailable and docs/comments describe tuning it.
Current behavior
- Template line uses a literal:
maxUnavailable: 1 worker.strategy.maxUnavailablefrom values is not wired into the rendered Deployment
Expected behavior
maxUnavailableshould be sourced from values, similar tomaxSurge- If unset, use a safe default (current behavior can remain the default)
Why this matters
Operators cannot apply intended rollout controls from values files, which can cause unexpected rollout speed/disruption in large worker fleets.
Suggested fix
In templates/worker/worker-deploy.yaml, replace hardcoded maxUnavailable: 1 with value lookup from worker.strategy.maxUnavailable and fallback default.
Acceptance criteria
helm templatereflectsworker.strategy.maxUnavailablewhen set in values.- Existing default behavior remains when not set.
scripts/install-dry-run.shchecks pass.
- Dominant language
- Go Template
- Stars
- 12
- Forks
- 24
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NatLabRockies/openstudio-server-helm
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Bug: kopf Body is Mapping, not dict — redis_layout_check isinstance guard silently skips validation Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 1/5 Under an hour Newbie friendliness 91/100
All issues in NatLabRockies/openstudio-server-helm
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
repo:raw-data
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
hotosm/raw-data-api#316 · 1 comment ·
-
agentic-workflows cascade-suspected
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
willow
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
openedx/openedx-authz#460 ·