deckhouse / deckhouse/deckhouse-cli
mirror push: PushParams.Parallelism is unused; push is sequential
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 20
- Forks
- 7
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 33
Description
Summary
d8 mirror push uploads images sequentially, but PushParams.Parallelism is populated and never read — it is dead configuration. This also makes the README "Best Practices → Parallel Operations" note misleading for push.
Details
internal/mirror/cmd/push/push.gosetsParallelism: params.ParallelismConfig{Blobs: ..., Images: ...}.pkg/libmirror/operations/params/push.godefinesParallelismConfigandDefaultParallelism.- No code reads
.Parallelism(only the definition and the assignment reference it), and the push path contains no concurrency primitives (go func,errgroup,sync.WaitGroup).internal/mirror/pusher/pusher.gopushes in a plain sequentialforloop.
Impact
Dead config; pushes of large bundles are slower than the config suggests, and documentation implying parallel push is inaccurate.
Expected
Either wire the Parallelism config into the pusher, or remove the unused config and adjust the docs.
Severity: low (cleanup / performance). As of main (62132d6a).
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.
Research direction
Start with internal/mirror/cmd/push/push.go, pkg/libmirror/operations/params/push.go, and internal/mirror/pusher/pusher.go to trace the configuration assignment and sequential push loop. Review the README Best Practices → Parallel Operations note, then determine whether the configuration should be wired in or removed; done means the implementation and documentation no longer contradict each other.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100