🌱 Bump sigs.k8s.io/kind to v0.29.0 #12257
Conversation
k8s-ci-robot
added
area/dependency
kishen-v
changed the title
|
/cc @sbueringer. |
|
/assign |
| @@ -83,22 +83,22 @@ var preBuiltMappings = []Mapping{ | |||
| { | |||
| KubernetesVersion: semver.MustParse("1.33.1"), | |||
| Mode: Mode0_20, | |||
| Image: "kindest/node:v1.33.1@sha256:8d866994839cd096b3590681c55a6fa4a071fdaf33be7b9660e5697d2ed13002", | |||
| Image: "kindest/node:v1.33.1@sha256:050072256b9a903bd914c0b2866828150cb229cea0efe5892e2b644d5dd3b34f", | |||
There was a problem hiding this comment.
If I remember well from previous bumps, what we usually do is to create a new section in this file with images for the new release.
Is there a specific reason why we are changing images for 0.28 in this bump?
There was a problem hiding this comment.
+1 we should add a new section
There was a problem hiding this comment.
Hm. @fabriziopandini Or given that we just bumped 2 days ago to v0.28. Is there any reason why we couldn't essentially "skip" v0.28? (by only having 0.29 here)
(In any case we should update the godoc comment in l.82)
There was a problem hiding this comment.
The published image tags (apart from the sha's) are also the same. Which means the v0.28 config would be basically dead code as far as I can tell?
There was a problem hiding this comment.
Hi @sbueringer and @fabriziopandini.,
Thanks for pointing out... As rightly understood, we've two versions of kind point to the same patch versions of kubernetes across minor releases..
Should it suffice to change L82 as : // Pre-built images for Kind v0.28 and v0.29
while essentially retaining the Version@SHA256 of the images built with kind 0.29, given that the vulnerability in containerd is patched through images bundled with the latest kind release?
Please let me know your thoughts.
Thanks!
There was a problem hiding this comment.
I would prefer picking one of these options but not mixing them
- only have a section for v0.29
- have one section for v0.28 and one for v0.29
I don't like the option of documenting that these images are for both versions while the sha's are only pointing to v0.29
I'll let @fabriziopandini choose :)
There was a problem hiding this comment.
Sure!
Just a thought, if we were to use the kind-node images bundled with v0.28 release, the node images would essentially contain containerd-v2.1, which contains the vulnerability.. We may need to steer clear of it!
There was a problem hiding this comment.
I think that's a good reason for option 1 (basically don't even have v0.28 in the mapper)
There was a problem hiding this comment.
I've updated the PR to contain the images from kind v0.29 alone. I'll keep a tab on this thread to accommodate further changes, if any.
Thanks!
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Let's wait for the resolution of #12257 (comment) But if we go with "only have a section for v0.29" /lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: 45f3c5817cd3219afe1038a5d00b4cb9bf578e8d
|
What this PR does / why we need it:
This PR bumps sigs.k8s.io/kind from v0.28.0 to v0.29.0 along with the associated node images from this release.
The images are based on the data available here:
http://github.com/kubernetes-sigs/kind/releases/tag/v0.29.0.
Which issue(s) this PR fixes (optional, in fixes #(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #12240
/area dependency