-
Notifications
You must be signed in to change notification settings - Fork 23
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
Add imagePullPolicy support to spinApp spec #197
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Ant Weiss <[email protected]>
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.
I don't think we'll want to support everything that the Pod Spec supports but this seems like a reasonable addition to me. LGTM!
ImagePullPolicy corev1.PullPolicy `json:"imagePullPolicy,omitempty"` | ||
// Checks defines health checks that should be used by Kubernetes to monitor the application. |
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.
Nit
ImagePullPolicy corev1.PullPolicy `json:"imagePullPolicy,omitempty"` | |
// Checks defines health checks that should be used by Kubernetes to monitor the application. | |
ImagePullPolicy corev1.PullPolicy `json:"imagePullPolicy,omitempty"` | |
// Checks defines health checks that should be used by Kubernetes to monitor the application. |
Agreed. No need to support the entire pod spec. And happy this looks reasonable. I hit this after 15 minutes playing with SpinKube and my guess I'm not the only one who'd expect this to be supported. |
Looks like your commit isn't signed. The contribution guide has more on doing that. Reach out if you get stuck on this. And I forgot to say, thanks for your contribution. Thank you! |
That's weird. I've spent about half an hour on setting up commit signing especially for this 😊 Ok, now I see I forgot to add the GPG key to Github. |
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.
I'm a little hesitant as to whether we do want to support this actually (it was a deliberate omission from the first release).
Encouraging the use of mutable tags results in a lot of complexity and long term debugging and support headaches - and the defaults are reasonable (https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting).
I'd rather guide folks towards having deterministic development environments (and being able to verify that they are actually testing the latest version of their code) than the confusion of the raciness of mutable image pulls 😅
The main argument for exposing some of this configuration is to allow exposing Never
for clusters that are airgapped - but I'd at that point be tempted to make Always
an error.
@endocrimes I see what you mean. Encouraging the use of mutable tags is definitely not something we want to do. Yet the default behavior seems to encourage the use of |
@antweiss It's a difficult balancing act between "flexibility" and pushing people towards safer practices. We don't encourage I would like to hear a little bit about why that's a thing you want and how it aids your development workflow though? The Kubernetes project gets a lot of issues from folks who get into very broken situations because of mutable tags and |
(I ask how this interacts with your development workflow because their are potentially some more stable options than relying on |
I've reported spinkube/spin-plugin-kube#70 to try out an alternative approach by handling this on |
To say the truth I wasn't even using the |
Implements #196