-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add ImagePullSecrets config private registries #9
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we document (with an example) the usage of the pod.template
feature where it's also possible to inject the image-pull secret instead of adding a new field and appending to the spec?
Appending the pullSecret via a new configuration-value only make sense to me, if we also take care of the lifecycle of the secret itself (IMHO)
WDYT?
@gabriel-samfira i'm also interested in your opinion about that 🙏 In general the support for adding an Both seems valid to me ATM |
@bavarianbidi yes you are right, with the podTemplate we have this defacto already implemented, and i like the config via podTemplateSpec better, tbh didn´t give much thought about this. IMH we should rather provide some better documentation on how podTemplateSpec behaves, and how flexible this solution is for configuring your runner pod. So i can close this draft, and update the docs |
TL;DR; Documenting that the pull secrets for the supplied registry can be set as pod spec values is okay. The key thing is to make it easy for users to understand how to deal with private registries. Even a quick example in the README is ok. TS;NM; In general, my personal preference is to keep all relevant dependencies grouped together. If an option is created to define a resource, from a user experience perspective, it's a good idea to have all relevant dependencies for that new option, clumped together in a single place. The registry and the credentials can be specified at the pod spec level, but we also have a config value at the provider level via the I would be okay with having the creds supplied as part of garm-cli pool add \
--image registry.example.com:5000/runner-image:latest \
--extra-specs='{"registry-secrets":{ "username": "admin", "password": "admin"}}' So there are 3 options here, either one being okay as far as I am concerned. |
I just realized, extra specs are not encrypted at rest, so this one is a bad idea (for now), and someting that I should fix in garm first. |
One can now supply a list of ImagePullSecrets for runner pods in the provider-config.yaml which are attached to a runner pod if configured, so images can be pulled from private registries as well: