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
Reference containerDisks and kernel boot images in reproducible format during migrations #6535
Reference containerDisks and kernel boot images in reproducible format during migrations #6535
Conversation
/retest |
/retest bazel cache server got restarted. |
/retest |
/hold It seems that if we migrate to a node which already has the image pulled via tag, then even if we pull with shasum, we would see in the status in |
2394a51
to
88f977e
Compare
/unhold |
/retest |
/cc @davidvossel ready for review. |
/cc @vasiliy-ul Maybe you want to do an initial review on this one. |
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.
Hey, thanks for pinging me here. This looks good. Just left a minor comment (can be ignored) and a general question.
diskContainerImage := volume.ContainerDisk.Image | ||
if img, exists := imageIDs[volume.Name]; exists { |
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.
Optional: In ExtractImageIDsFromSourcePod
the returned map is initialized with empty strings ""
for each volume. Maybe it would be safer to check:
if img, exists := imageIDs[volume.Name]; exists { | |
if img, _ := imageIDs[volume.Name]; len(img) > 0 { |
pkg/container-disk/container-disk.go
Outdated
if _, exists := imageIDs[key]; !exists { | ||
continue | ||
} | ||
imageIDs[key] = status.ImageID |
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.
Are you sure that ContainerStatus.ImageID
is always in the form of name@sha256:<digest>
? I wasnt able to find some specific info about that in the docs but after googling a bit it seems that it may depend on the container runtime. E.g. here https://stackoverflow.com/questions/45612310/get-the-image-and-sha-image-id-of-images-in-pod-on-kubernetes-deployment it is
"imageID": "docker://sha256:b8efb18f159bd948486f18bd8940b56fd2298b438229f5bd2bcf4cedcf037448"
If that is the case then can't it cause issues when migrating VMs between nodes with different runtimes?
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.
Hm, that is a good point. If so it may be necessary to grep for sha256:<>
and extract it, but not sure if this is something i would consider stable enough ...
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.
Indeed, on kind
it look like this: imageID: sha256:e422121c9c5f97623245b7e600eeb5e223ee623f21fa04da985ae71057d8d70b
But there seems to be always the sha256
present at least.
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.
So
- cri-o: the full containerID
<registry>/<name>@sha256:<>
- docker (not directly containerd):
docker://sha256:<>
- containerd:
sha256:<>
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.
Seems that yes, the digest is always there. Probably then better to extract it and combine with the image name.
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.
Addressed. PTAL.
/hold Not fit for all container runtimes. |
pkg/container-disk/container-disk.go
Outdated
@@ -53,6 +54,9 @@ const KernelBootVolumeName = KernelBootName + "-volume" | |||
|
|||
const ephemeralStorageOverheadSize = "50M" | |||
|
|||
var digestRegex = regexp.MustCompile(`sha256:([a-zA-Z0-9]+)`) | |||
var containerBaseRegex = regexp.MustCompile(`^[^@:]+`) |
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.
hm... not sure the regexp will work correctly if a port number is specified for the registry: registry:5000/kubevirt/cirros-container-disk-demo:devel
.
Also I can specify an image with digest directly in the VMI spec: registry:5000/kubevirt/cirros-container-disk-demo@sha256:<digest>
. Maybe worth adding a unit testcase for that.
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.
Indeed it does not :) Also looking for a utility function in our vendor dependencies but did not find one yet.
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.
Maybe makes sense to just trim the string from the right up to the first (last since its from the right) :
(this will remove the tag or the digest). Then just TrimSuffix("@sha256")
. I guess should work. UPD: nah, an image can be specified without tag (assuming 'latest')...
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 think I have it now.PTAL.
0afb870
to
d6256d3
Compare
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.
Looks good. Just a small question inline.
pkg/container-disk/container-disk.go
Outdated
parts := strings.Split(image, "/") | ||
if strings.Contains(parts[len(parts)-1], "@") { | ||
|
||
} |
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.
hm... what is the point of this parts
and an empty if
? maybe a leftover?
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.
ha. Indeed. Fixed.
15cc1ee
to
d411325
Compare
/lgtm |
@davidvossel I would love to hear a second opinion on this. |
Every container runtime reports the imageID slightly different. However they all contain the digest in a form which can be extracted via regexp by searching for `sha256:<digest>`. If the digest can't be extracted the migration will not proceed to avoid corrupting guests. Signed-off-by: Roman Mohr <rmohr@redhat.com>
d411325
to
7c6231e
Compare
@vasiliy-ul @davidvossel rebased. PTAL. |
/lgtm |
/unhold |
/retest |
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: davidvossel The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
4 similar comments
/retest |
/retest |
/retest |
/retest |
@rmohr: The following tests failed, say
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. I understand the commands that are listed here. |
/retest |
/cherrypick release-044 |
/cherrypick release-0.44 |
@rmohr: cannot checkout 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. |
@rmohr: #6535 failed to apply on top of branch "release-0.44":
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. |
…igrations Reference containerDisks and kernel boot images in reproducible format during migrations (cherry picked from commit 901f705) Signed-off-by: Roman Mohr <rmohr@redhat.com>
What this PR does / why we need it:
Tags pointing to a container digest can change after a VMI was started (especially
:latest
). If that happens we pull the wrong containerDisk or kernel boot image in the new pod, leading to potentially corrupt state or to a failed migration because qemu refuses to start on a different disk.This is a long know issue which is now resolved the following way: Once a migration starts, the migration controller looks at the source pod and extracts the digest of images (always visible in the pod status) and uses that digest instead of the originally user-supplied value on the target pod.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Release note: