-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Consider pinning kind images to a sha #8815
Comments
/triage accepted If it is required to make us compliant with kind recommendations, I'm +1 |
For 2 I would prefer to always build ourselves. Except there is a low maintenance way to automatically use compatible images or build ourselves. I wonder how this will affect CAPD users (quick start). Would they have to specify the version with Sha? Or would we have an allow list with Kubernetes versions that we automatically map to hardcoded Shas? I think it's tricky as we still want to make sure self-build images work as well |
I think mapping versions -> known SHAs is the only real way for us to do this. The easiest way to do so is to keep an updated list in the repo, but it requires some manual effort - mostly the KIND bump + when using a new version of Kubernetes. I'm also fine with making the e2e tests always-build. We should enable pinning images by sha at the same time though - some logic like if it has a SHA use it, if not always build - so we can speed up upgrade tests running locally etc. |
Hm yup. Maybe it's fine if it's just part of the kind bump to update the list in some go file
Yup. Maybe just a small test helper binary that reads the list in the go file and tells us if we have to build ourselves Just had another idea for users.
|
/assign I'd like to get this done ahead of the KIND v0.20.0 release so we don't have to deal with the issues described in #6264 until we update. Basic approach:
We can treat automatically resolving known-good images as a follow up as it's not completely essential here. It may begin to impact CAPD users soon though. |
/close The following were done to resolve this issue:
Going forward the list of KIND shas will need to be updated with each new KIND release so that we're normally using the latest images available. We might be able to find some way to automate this in future. |
@killianmuldoon: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@killianmuldoon kudos for all the hard work here, this is keeping the light on for the next release |
We currently set KIND image versions either by their tag or using logic to retrieve the latest stable image for a certain minor release of Kubernetes. This is against KIND's guidelines as outlined in the release notes:
And also in this comment from @BenTheElder #8788 (comment)
We should consider pinning the images we use from KIND. Currently we set the version in a few places:
(I may have missed some other places)
We could solve (1) fairly easily by just pinning the tag to a known
kindest/node
release with the relevant sha.For (2) and (3), though we'd need a source of truth - just a yaml file or similar - with a list of Kubernetes versions linked to the current KIND release. This would need to be updated at least for every KIND release and likely Kubernetes release (when a
kindest/node
image gets published. I'm not sure if the images have any other markers or labels we could use to distinguish this.For the e2e tests when we don't have an images for the latest version of Kuberntes available it can be built on the fly. This will make upgrade tests take longer and use more CPU etc., but these tests only run once a day so they're not that intensive.
For resolving images for CAPD we would probably need to return good errors / warnings so users know that some images that may have worked in the passed will no longer be used by CAPI e.g. after upgrading to KIND v0.20.0 there may not be a recommended v1.27.0 image.
We can tackle all three of these problems separately, as they're decoupled. The only one which has hard tradeoffs IMO is (3) so it would be good to hear more opinions on ways to deal with it.
Ref: #8788
The text was updated successfully, but these errors were encountered: