zalando-incubator / zalando-incubator/stackset-controller
Separate TTL for newly created stacks
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 183
- Forks
- 29
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 5
Description
#71 implemented a hacky solution to a problem where the controller scaled down stacks before the deployment even had a chance to switch traffic to those. However, this behaviour is not exactly intuitive, and could lead to deployments being kept alive for longer than necessary if the user quickly switches traffic back and forth. A cleaner approach would be to mark newly created stacks with an annotation that's erased when they get traffic and introducing a separate TTL for stacks in this state.
Contributor 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.
Research direction
Start by reviewing the behavior introduced in #71 and tracing how the controller identifies newly created stacks, traffic switches, annotations, and TTL-based scale-down decisions. Define the annotation lifecycle and separate TTL behavior, including rapid traffic changes, then verify that stacks receive traffic before the new TTL expires and that the annotation is removed afterward.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100