Make the DaemonSet's rolling-update width a chart value
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- kubernetes
- Domain
- devops, infrastructure
Research direction
Start with deploy/helm/pacer/templates/daemonset.yaml and the chart values used by the DaemonSet and PodDisruptionBudget. Trace how each maxUnavailable setting is rendered, then review the existing comments and ADR-0036 before documenting the trade-off and measured per-node rollout time. Done means one defaulted chart value controls both settings and the operator-facing guidance is updated.
Written by the indexing model from the issue text.
Description
The DaemonSet's updateStrategy.rollingUpdate.maxUnavailable is fixed at 1 in deploy/helm/pacer/templates/daemonset.yaml. The PodDisruptionBudget's is a value (podDisruptionBudget.maxUnavailable), and its comment says it matches the update strategy, but only one of the two can be changed.
Each node's restart includes the shutdown drain (up to 20 s, ADR-0036), RDMA memory registration (the startup probe allows up to 5 minutes) and the disk-tier scan. A rollout takes that time multiplied by the number of nodes, so on a large fleet a version or config change can take hours.
Proposed:
- one chart value that sets both the update strategy and the PDB, defaulting to 1;
- document the trade-off. With
replication_r: 2, taking more than one node down at a time means some chunks have no ready home and are read from S3 until the nodes return. Allowing more than R-1 nodes down at once trades that S3 load for a shorter rollout; - document the expected rollout time per node, measured, so an operator can plan a change window.
- Dominant language
- Rust
- Stars
- 16
- Forks
- 1
- Avg merge
- 7h 19m
- Merged PRs (30d)
- 29
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
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 aws-samples/sample-pacer
-
Measure requester-mode hit rate with diskTier=store — the disk slot may drop every ETag witnessOpen
Difficulty 3/5 1-2 days Newbie friendliness 68/100
aws-samples/sample-pacer#73 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 42/100
aws-samples/sample-pacer#72 · 1 comment ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
aws-samples/sample-pacer#71 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
aws-samples/sample-pacer#69 ·
Maintainers usually reply within 1 day
-
enhancement rust
Difficulty 5/5 Over a week Newbie friendliness 45/100
aws-samples/sample-pacer#67 ·
Maintainers usually reply within 1 day
All issues in aws-samples/sample-pacer
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
farion1231/cc-switch#8829 ·
Maintainers usually reply within 1 day
-
bug ci good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
longbridge/gpui-kit#3677 ·
Maintainers usually reply within 1 day
-
E-pr-welcome
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
seanmonstar/reqwest#3121 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
ilya-zlobintsev/LACT#1235 ·
Maintainers usually reply within 1 day