Bug 1879993 - v2v-conversion-image is not updated during CNV upgrade from 2.4.0 to 2.4.1
Summary: v2v-conversion-image is not updated during CNV upgrade from 2.4.0 to 2.4.1
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Installation
Version: 2.4.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 2.5.0
Assignee: Simone Tiraboschi
QA Contact: Guy Inger
URL:
Whiteboard:
: 1879994 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-17 14:06 UTC by Fabien Dupont
Modified: 2023-12-15 19:27 UTC (History)
9 users (show)

Fixed In Version: 2.5.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-07 09:53:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt hyperconverged-cluster-operator pull 832 0 None closed Reconcile IMS ConfigMap 2020-11-22 12:34:11 UTC
Github kubevirt hyperconverged-cluster-operator pull 841 0 None closed [release-1.2] Reconcile IMS ConfigMap 2020-11-22 12:34:34 UTC
Red Hat Issue Tracker CNV-7340 0 None None None 2023-12-15 19:27:50 UTC

Internal Links: 1884538

Description Fabien Dupont 2020-09-17 14:06:06 UTC 
Description of problem:

When upgrading CNV from 2.4.0 to 2.4.1, the "v2v-conversion-image" attribute of the "v2v-vmware" config map is not updated with the SHA256 signature of the image for 2.4.1. The consequence is that the import will still use the 2.4.0 image.


To find what the SHA256 signature of an image is, one can use the following commands:

$ podman login registry.redhat.io
$ podman pull registry.redhat.io/container-native-virtualization/kubevirt-v2v-conversion:v2.4.0
$ podman inspect registry.redhat.io/container-native-virtualization/kubevirt-v2v-conversion:v2.4.0 | jq '.[]["Digest"]'

The SHA256 in "v2v-conversion-image" was "e3056e80f0aecf186bfac6504f23aa58d33120d0ba9646a816bd4f341b030cae", while should have been "f160e205506908b7145a1414158721c9c01ffdcf12f55ebe38d8f22432a92d08".


Version-Release number of selected component: 2.4.0 and 2.4.1
Comment 2 Brett Thurber 2020-09-22 18:40:07 UTC 
*** Bug 1879994 has been marked as a duplicate of this bug. ***
Comment 3 Tomáš Golembiovský 2020-09-24 10:40:06 UTC 
Brett, do we expect users to change the configmap or is it safe to reconcile it on every update and overwrite any user changes?
Comment 4 Brett Thurber 2020-09-25 14:56:27 UTC 
(In reply to Tomáš Golembiovský from comment #3)
> Brett, do we expect users to change the configmap or is it safe to reconcile
> it on every update and overwrite any user changes?

We would want to preserve if possible.
Comment 6 Fabien Dupont 2020-10-01 19:21:23 UTC 
I'm afraid that it block import from VMware. Whenever the "vddk-init-image" entry is added, the HCO reconciler removes it as it's not an updatable entry.
Comment 7 Inbar Rose 2020-10-15 12:17:26 UTC 
(In reply to Fabien Dupont from comment #6)
> I'm afraid that it block import from VMware. Whenever the "vddk-init-image"
> entry is added, the HCO reconciler removes it as it's not an updatable entry.

does this require re-opening the bug or filing a new bug?
Comment 9 Fabien Dupont 2020-10-20 06:42:24 UTC 
@irose this was fixed in https://bugzilla.redhat.com/show_bug.cgi?id=1884538.
Note You need to log in before you can comment on or make changes to this bug.