Created attachment 1714443 [details] PVC screenshot Description of problem: When creating a golden image PVC, the user can select an operating system to attach the PVC to. The list is taken from the avaialble common templates. We have one template per one major release (i.e RHEL7 and RHEL8), and minor releases are encorporated into the major release template. As a result, when an OS is selected (e.g RHEL8), the PVC name is hardcoced (taken from PVC_NAME in the template, e.g rhel8.2), leading to: 1. Only on eimage can be attached to a release; it is impossible to upload RHEL8.1 and RHEL8.2 images 2. The PVC name cannot be modified, so a user would like to upload RHEL8.1, the PVC name would still be rhel8.2 Version-Release number of selected component (if applicable): CNV 2.5 How reproducible: 100% Steps to Reproduce: In the UI: 1. Storage - > Persistemt Volume Claims -> create "with data upload form" 2. Check the "Attach this data to a Virtual Machine operating system" checkbox 3. Select an OS from the list Actual results: 1. PVC name is hardcoced 2. Only one PVC per major release Expected results: A suer can upload a golden image per minor release Additional info: See attached screenshot
Fedora templates should also be addressed, currently the last label is used: name: SRC_PVC_NAME value: silverblue32
I have a PR for this here - https://github.com/kubevirt/common-templates/pull/227
This is now relevant to Windows server OS. In the UI, the PVC can be attached to Microsoft Windows Server 2012 R2 / Microsoft Windows Server 2016 / Microsoft Windows Server 2019. However, as there's only one SRC_PVC_NAME in the template, the PVC name for all options is "win2k19"
Created attachment 1719250 [details] Screenshot - PVC attached to Win16
@Shweta the only solution to this I see is splitting up the windows.tpl meta template to windows2k12.tpl, windows2k16.tpl, windows2k19.tpl and generate standalone templates for each of them (the same is done for RHEL), and only then you can specify a proper PVC name for each windows version. Currently we have the following templates: --- windows-server-large.yaml windows-server-medium.yaml --- After the change I proposed we will have: --- windows2k12-server-large.yaml windows2k12-server-medium.yaml windows2k16-server-large.yaml windows2k16-server-medium.yaml windows2k19-server-large.yaml windows2k19-server-medium.yaml --- @Tomas To my understanding, this proposed change will not affect the UI as long as a [os/size/flavor] label trio matches a single template, can you confirm?
To be on the safe side, deferring to Yaacov
> To my understanding, this proposed change will not affect the UI as long as a [os/size/flavor] label trio matches a single template, can you confirm? I think you have a typo [os/size/flavor] should be [os/workload/flavor] ? yes, a. we need os, flavor and workload to match one template. b. we use the `name.os.template.kubevirt.io/...` annotation to create a list of unique os names, so if will be nice to have a 1:1 matching between the OS name and the PVC disk name.
For ref: https://bugzilla.redhat.com/show_bug.cgi?id=1882421 - UI should handle multiple more then one PVC disk option per OS gracefully.
> a. we need os, flavor and workload to match one template. > b. we use the `name.os.template.kubevirt.io/...` annotation to create a list > of unique os names, so if will be nice to have a 1:1 matching between the OS > name and the PVC disk name. I don't think b should be an issue, Shweta and I will look into it Thanks!
(In reply to Omer Yahud from comment #14) > > a. we need os, flavor and workload to match one template. > > b. we use the `name.os.template.kubevirt.io/...` annotation to create a list > > of unique os names, so if will be nice to have a 1:1 matching between the OS > > name and the PVC disk name. > > I don't think b should be an issue, Shweta and I will look into it > Thanks! To stay on the safe side, before you merge, could you please create some env where the templates follow this we can connect our UI to to check that everything works nice together?
> To stay on the safe side, before you merge, could you please create some env > where the templates follow this we can connect our UI to to check that > everything works nice together? Would a quicklab env do the trick?
(In reply to Omer Yahud from comment #16) > > To stay on the safe side, before you merge, could you please create some env > > where the templates follow this we can connect our UI to to check that > > everything works nice together? > > Would a quicklab env do the trick? any ocp env with cnv installed I can oc login to will do
@Shweta, please also add a test case that validates that every label trio [os/workload/flavor] returns a single template
Here is the PR - https://github.com/kubevirt/common-templates/pull/242
Tomas was able to connect to my cluster and view the new Windows templates in the UI. Waiting for the PR to be reviewed and approved.
Tested with kubevirt-ssp-operator-container-v2.5.0-55: There are 2 redundant windows server templates: windows-server-large-v0.12.3 and windows-server-medium-v0.12.3 (which do not have any relevant template labels): $ oc get template -n openshift |grep -i win|grep server|grep -v win2k12r2 windows-server-large-v0.12.3 Template for Microsoft Windows Server 2012 R2 VM or newer. A PVC with the Win... 4 (1 blank) 1 windows-server-medium-v0.12.3 Template for Microsoft Windows Server 2012 R2 VM or newer. A PVC with the Win... 4 (1 blank) 1 windows2k12r2-server-large-v0.12.3 Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 4 (1 blank) 1 windows2k12r2-server-medium-v0.12.3 Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 4 (1 blank) 1 windows2k16-server-large-v0.12.3 Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 4 (1 blank) 1 windows2k16-server-medium-v0.12.3 Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 4 (1 blank) 1 windows2k19-server-large-v0.12.3 Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 4 (1 blank) 1 windows2k19-server-medium-v0.12.3 Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 4 (1 blank) 1
Actually, these are deprecated templates (before the split to OS versions). Verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Virtualization 2.5.0 Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:5127