support custom registry image with `create cluster`
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 722
- Forks
- 48
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 8
Description
The --registry arg to ctlptl create cluster will ensure that ctlptl creates a registry for the cluster it creates.
ctlptl create registry has support for specifying a custom image. If a user creates a registry using that, and then tries to create a cluster using that registry, ctlptl will delete and recreate the registry with the default image (the test, desired.Image (hardcoded to empty string)).
I tried a bit to work around this by first creating the cluster, then deleting the registry, recreating it with a custom image name, and adding it to the docker network, but didn't manage to get it to work. Even if I could get it to work, that rather defeats the point of using ctlptl in the first place.
The two (compatible) main options I see are:
- add a
--registry-imagearg toctlptl create cluster. This would presumably best solve the common case. - add some way to tell
ctlptl create clusterto skip registry creation and just connect to an existing registry. This would presumably leave a better escape hatch for any similar problem (for example).
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 with the registry behavior in pkg/registry/registry.go around the linked test and the cluster handling in pkg/cluster/cluster.go around desired.Image. Compare the existing custom-image support with the hardcoded empty image used by cluster creation. Resolve whether the change should add a registry-image option or support an existing registry, then add coverage showing the registry is not recreated with the default image.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go, kubernetes
- Domain
- cli, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100