Description of problem: VM Templates not listed in Workloads -> Virtualization -> Templates tab Version-Release number of selected component (if applicable): OCP 4.8.0-0.nightly-2021-05-21-233425 hco-bundle-registry-container-v4.8.0-353: 76555 How reproducible: Always (previous working iib release as well) Steps to Reproduce: 1. Install CNV via above mentioned hco bundle (brew) 2. View Workloads -> Virtualization -> Templates 3. (OR) Workloads -> Virtualization , Create new VM with wizard Actual results: No Virtual Machine Templates Found Expected results: List of templates to install from Additional info: Templates are installed in openshift namespace: metadata from windows2k19-server-large: kind: Template metadata: annotations: defaults.template.kubevirt.io/disk: rootdisk defaults.template.kubevirt.io/network: default description: Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk image must be available. iconClass: icon-windows name.os.template.kubevirt.io/win2k19: Microsoft Windows Server 2019 openshift.io/display-name: Microsoft Windows Server 2019 VM openshift.io/documentation-url: https://github.com/kubevirt/common-templates openshift.io/provider-display-name: KubeVirt openshift.io/support-url: https://github.com/kubevirt/common-templates/issues operator-sdk/primary-resource: openshift-cnv/ssp-kubevirt-hyperconverged operator-sdk/primary-resource-type: SSP.ssp.kubevirt.io tags: hidden,kubevirt,virtualmachine,windows template.kubevirt.io/deprecated: "true" template.kubevirt.io/editable: | /objects[0].spec.template.spec.domain.cpu.cores /objects[0].spec.template.spec.domain.resources.requests.memory /objects[0].spec.template.spec.domain.devices.disks /objects[0].spec.template.spec.volumes /objects[0].spec.template.spec.networks template.kubevirt.io/provider: Red Hat template.kubevirt.io/provider-support-level: Full template.kubevirt.io/provider-url: https://www.redhat.com template.kubevirt.io/version: v1alpha1 template.openshift.io/bindable: "false" creationTimestamp: "2021-05-25T17:45:16Z" labels: app.kubernetes.io/component: templating app.kubernetes.io/managed-by: ssp-operator app.kubernetes.io/name: common-templates app.kubernetes.io/part-of: hyperconverged-cluster app.kubernetes.io/version: v4.8.0 flavor.template.kubevirt.io/large: "true" os.template.kubevirt.io/win2k19: "true" template.kubevirt.io/type: base template.kubevirt.io/version: v0.14.0 workload.template.kubevirt.io/server: "true" name: windows2k19-server-large namespace: openshift resourceVersion: "394790" uid: b2947247-72f4-4c4a-9eda-e969632f035b
Could you try below command from cli to see what it get: $ oc get template -n openshift -l template.kubevirt.io/default-os-variant=true From here, the output looks like below and which are showing on UI: $ oc get template -n openshift -l template.kubevirt.io/default-os-variant=true NAME DESCRIPTION PARAMETERS OBJECTS centos7-server-small Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos8-server-small Template for CentOS 8 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 fedora-server-small Template for Fedora 32 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 rhel6-server-small Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-small Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-small Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 windows10-desktop-medium Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows2k12r2-server-medium Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k16-server-medium Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-server-medium Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1
If it returns nothing it means it's not installed properly, then please move to installation or ssp for investigation.
I get the same output you do. The template I pasted the metadata for earlier is installed properly. The bug seems to be in some filter applied by the UI.
@Chandler, hi thank you for the issue, I can't reproduce using OCP 4.8.0-fc.5 and CNV installed from HCO (git master), I may be missing something in the Steps to Reproduce, or this specific nightly version has a bug fixed in later versions. Can you attach screenshots of steps you are taking to reproduce ? Can you try with a newer nightly / not-nightly OCP ?
If this is a reproducible issue, it will be a blocker. Let's wait for the feedback.
Note: This is one way to install HCO from git master: curl https://raw.githubusercontent.com/kubevirt/hyperconverged-cluster-operator/master/deploy/deploy.sh | bash like any install from git master, it may fail in unexpected ways ...
Chandler hi, I can't reproduce, can we close this bug ?
it looks like the templates has an anotatoin: template.kubevirt.io/deprecated: "true" The UI will not suggest detracted templates by design. Moving to SSP as this templates should not be deprecated.
I don't know how all templates could be marked as deprecated on a proper install (any install tbh.). Maybe @ksimon knows that?
Note on how to reproduce: Any template that does not have the exact version label: https://github.com/kubevirt/ssp-operator/blob/master/internal/operands/common-templates/reconcile.go#L167 Will be marked as deprecated: https://github.com/kubevirt/ssp-operator/blob/master/internal/operands/common-templates/reconcile.go#L192
yes, that is how it works. Weird thing is, that the template in first post has version template.kubevirt.io/version: v0.14.0 and the version set in ssp operator is v0.14.0 as well (https://github.com/kubevirt/ssp-operator/blob/release-v0.11/internal/operands/common-templates/version.go#L11). @Chandler Wilkerson can you please share log from ssp operator or share credentials to cluster where this happened?
I have since reinstalled (and run into blocking issues with the reinstall) and no longer have access to the version of the cluster where this happened.
@cwilkers Do you have a way to reproduce this? Any step by step installation procedure maybe?
Apologies, I am still unable to access my cluster (The install issues I mentioned were followed by planned hardware maintenance in our lab, and that maintenance is expected to last through Monday) I could certainly see where @yzamir 's point on older versioned templates getting marked deprecated could have happened to me due to a mismatch in version numbers between the CNV operator subscription and catalog. It seems like checking for the deprecation annotation in the default templates is something that could easily be handled in QE's smoke tests, if it is not already there. As far as I'm concerned, if you cannot reproduce, it's likely something unique on my end due to the above-mentioned misconfiguration. I'm okay to close.
btw/ it just happened to us in our dev cluster. we have HCO installed with one version and somehow (maybe someone installed it using operator hub ?) openshift-virtualization got installed. all templates got marked as deprecated ... So the only way we could reproduce is by installing to versions of SSP on the same cluster ...
@cwilkers Can we close this bug?
@rnester Yes, I was able to reinstall and verify templates were there after fixing my CNV subscription YAML.
@ksimon I managed to reproduce it on an upgrade flow. OCP 4.7 and CNV 2.6.3 Upgraded OCP to 4.8.0-fc.9 Upgraded CNV to 2.6.4 and then to 2.6.5 and then to 4.8.0 Templates are marked as deprecated: apiVersion: template.openshift.io/v1 kind: Template metadata: annotations: defaults.template.kubevirt.io/disk: rootdisk description: Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk image must be available. iconClass: icon-rhel name.os.template.kubevirt.io/rhel8.0: Red Hat Enterprise Linux 8.0 or higher name.os.template.kubevirt.io/rhel8.1: Red Hat Enterprise Linux 8.0 or higher name.os.template.kubevirt.io/rhel8.2: Red Hat Enterprise Linux 8.0 or higher name.os.template.kubevirt.io/rhel8.3: Red Hat Enterprise Linux 8.0 or higher name.os.template.kubevirt.io/rhel8.4: Red Hat Enterprise Linux 8.0 or higher openshift.io/display-name: Red Hat Enterprise Linux 8.0+ VM openshift.io/documentation-url: https://github.com/kubevirt/common-templates openshift.io/provider-display-name: KubeVirt openshift.io/support-url: https://github.com/kubevirt/common-templates/issues operator-sdk/primary-resource: openshift-cnv/ssp-kubevirt-hyperconverged operator-sdk/primary-resource-type: SSP.ssp.kubevirt.io tags: hidden,kubevirt,virtualmachine,linux,rhel template.kubevirt.io/deprecated: "true" I will try to reproduce it on another cluster. @cwilkers fyi
Happned on CNV 2.6.5 to 4.8.0 upgrade (SSP 4.8.0-38). Marking as proposed blocker.
Verified OCP 4.6+CNV 2.56 -> OCP 4.7+CNV 2.6.5 -> OCP 4.8.0+CNV 4.8.0-451: Templates are not marked as deprecated and are usable from the UI
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 (Moderate: OpenShift Virtualization 4.8.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/RHSA-2021:2920