Bug 1877391 - kubevirt-hyperconverged-operator.v2.4.1 not found
Summary: kubevirt-hyperconverged-operator.v2.4.1 not found
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Installation
Version: 2.4.1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: 2.4.2
Assignee: Simone Tiraboschi
QA Contact: Inbar Rose
URL:
Whiteboard:
Depends On: 1877564
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-09 14:20 UTC by Jenifer Abrams
Modified: 2020-11-30 11:03 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-11 17:19:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jenifer Abrams 2020-09-09 14:20:14 UTC
Description of problem:
I have an existing 4.5.5 cluster, trying to install CNV 2.4.1 following the CLI doc: https://docs.openshift.com/container-platform/4.5/virt/install/installing-virt-cli.html

However the deploy makes no progress and the catalog-operator logs show the 2.4.1 release is "not found":

ime="2020-09-09T13:57:06Z" level=info msg=syncing event=update reconciling="*v1alpha1.Subscription" selflink=/apis/operators.coreos.com/v1alpha1/namespaces/openshift-sriov-network-operator/subscriptions/sriov-network-operator-subscription
time="2020-09-09T13:58:01Z" level=info msg=syncing event=update reconciling="*v1alpha1.Subscription" selflink=/apis/operators.coreos.com/v1alpha1/namespaces/openshift-cnv/subscriptions/hco-operatorhub
time="2020-09-09T13:58:01Z" level=info msg=syncing event=update reconciling="*v1alpha1.Subscription" selflink=/apis/operators.coreos.com/v1alpha1/namespaces/openshift-cnv/subscriptions/hco-operatorhub
E0909 13:58:01.793882       1 queueinformer_operator.go:290] sync {"update" "openshift-cnv"} failed: {kubevirt-hyperconverged 2.4 kubevirt-hyperconverged-operator.v2.4.1 {redhat-operators openshift-marketplace}} not found: rpc error: code = Unknown desc = no entry found for kubevirt-hyperconverged 2.4 kubevirt-hyperconverged-operator.v2.4.1
E0909 13:58:01.802058       1 queueinformer_operator.go:290] sync "openshift-cnv" failed: {kubevirt-hyperconverged 2.4 kubevirt-hyperconverged-operator.v2.4.1 {redhat-operators openshift-marketplace}} not found: rpc error: code = Unknown desc = no entry found for kubevirt-hyperconverged 2.4 kubevirt-hyperconverged-operator.v2.4.1
time="2020-09-09T13:58:01Z" level=info msg=syncing event=update reconciling="*v1alpha1.Subscription" selflink=/apis/operators.coreos.com/v1alpha1/namespaces/openshift-cnv/subscriptions/hco-operatorhub
E0909 13:58:02.002589       1 queueinformer_operator.go:290] sync {"update" "openshift-cnv"} failed: {kubevirt-hyperconverged 2.4 kubevirt-hyperconverged-operator.v2.4.1 {redhat-operators openshift-marketplace}} not found: rpc error: code = Unknown desc = no entry found for kubevirt-hyperconverged 2.4 kubevirt-hyperconverged-operator.v2.4.1
[...]


Version-Release number of selected component (if applicable):
# oc version
Client Version: 4.5.5
Server Version: 4.5.5
Kubernetes Version: v1.18.3+08c38ef

Comment 1 Simone Tiraboschi 2020-09-09 14:34:42 UTC
This is just OLM not correctly refreshing operator hub content from the AppRegistry,
as a workaround I can suggest to run:
 oc patch operatorhub.config.openshift.io/cluster -p='{"spec":{"disableAllDefaultSources":true}}' --type=merge
 oc patch operatorhub.config.openshift.io/cluster -p='{"spec":{"disableAllDefaultSources":false}}' --type=merge

to force OLM to refresh the content.

Then we need to keep investigating it.

Jenifer, can you please try applying the suggested workaround on your cluster?

Comment 2 Jenifer Abrams 2020-09-09 14:41:03 UTC
Thanks Simone! That workaround to refresh OLM did the trick and now it is progressing:

NAME                                      DISPLAY                    VERSION   REPLACES   PHASE
kubevirt-hyperconverged-operator.v2.4.1   OpenShift Virtualization   2.4.1                Installing

Do you want to close this bug if the OLM problem is tracked elsewhere?

Comment 3 Fabian Deutsch 2020-09-10 08:18:41 UTC
Simone, the refresh helped.

How would the system have fixed the issue? How much time would this have taken?

Why did Jenifer run into this issue? Would a regular user run into it as well?

Comment 4 lgallett 2020-09-10 13:42:46 UTC
OLM is tracking this bug here https://bugzilla.redhat.com/show_bug.cgi?id=1877484

Comment 5 lgallett 2020-09-10 13:44:26 UTC
this is the 4.5.z bug https://bugzilla.redhat.com/show_bug.cgi?id=1877564

Comment 6 Simone Tiraboschi 2020-09-10 14:20:50 UTC
(In reply to Fabian Deutsch from comment #3)

> How would the system have fixed the issue? How much time would this have
> taken?
> Why did Jenifer run into this issue? Would a regular user run into it as
> well?

This is not CNV specific, I fear that without a forced refresh OLM will never notice it.
The proposed workaround can be considered safe enough to be proposed to customers in a KBS article until we will get a fix in a future release of OCP.

Comment 7 Inbar Rose 2020-09-13 07:40:02 UTC
(In reply to Simone Tiraboschi from comment #6)
> (In reply to Fabian Deutsch from comment #3)
> 
> > How would the system have fixed the issue? How much time would this have
> > taken?
> > Why did Jenifer run into this issue? Would a regular user run into it as
> > well?
> 
> This is not CNV specific, I fear that without a forced refresh OLM will
> never notice it.
> The proposed workaround can be considered safe enough to be proposed to
> customers in a KBS article until we will get a fix in a future release of
> OCP.


How do you suggest we prepare for testing this fix? Can we emulate the circumstances of this bug manually somehow? Is this something we can even test or should we rely on that bug fix?

Comment 8 Nelly Credi 2020-09-21 14:54:02 UTC
OCP issue fixed. moving to ON QA


Note You need to log in before you can comment on or make changes to this bug.