Bug 1869365 - CNV 2.5 deployment in disconnected cluster - failing
Summary: CNV 2.5 deployment in disconnected cluster - failing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Installation
Version: 2.5.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 2.5.1
Assignee: Oren Cohen
QA Contact: Asher Shoshan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-17 17:36 UTC by Asher Shoshan
Modified: 2020-11-17 13:24 UTC (History)
5 users (show)

Fixed In Version: 2.5.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-17 13:24:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2020:5127 0 None None None 2020-11-17 13:24:32 UTC

Description Asher Shoshan 2020-08-17 17:36:09 UTC
Description of problem:

Deploy of CNV 2.5 (Kustomize.sh) failing in a disconnected cluster


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Deploy disconnected OCP 4.6 cluster
2. Apply a disconnected IIB - named "rh-verified-operators"
2. Deploy CNV 2.5  -   CNV_SOURCE=brew,  CNV_VERSION=2.5
3.

Actual results:
Failed

Expected results:
Succeed

Additional info:

20:28:10 ++ /root/cnv-qe.rhcloud.com/BM-cnvqe-cnvcl4/bin/oc get catsrc rh-verified-operators -n openshift-marketplace -o 'jsonpath={.metadata.name}' --ignore-not-found
20:28:21 + CAT_SRC=rh-verified-operators
20:28:21 + '[' -n rh-verified-operators ']'
20:28:21 ++ /root/cnv-qe.rhcloud.com/BM-cnvqe-cnvcl4/bin/oc get opsrc rh-verified-operators -n openshift-marketplace -o 'jsonpath={.metadata.name}' --ignore-not-found
20:28:21 error: the server doesn't have a resource type "opsrc"
20:28:21 + OP_SRC=
20:28:21 + rm -rf /tmp/tmp.S1Ep3plhXI

Comment 6 Oren Cohen 2020-09-23 13:03:18 UTC
hi @Inbar,

The issues @Asher raised were:
1. It can be determined if the cluster on which the script is running on, is disconnected or not, based on the value of the OperatorHub custom resource, and we don't want additional parameter for the script for that.
2. The subscription is pointing to a catalog source named "hco-catalogsource" which is dynamically created by the kustomize script. However, in a disconnected cluster, there is no such catalog source name. (the existing catalog sources are not being touched if the cluster is disconnected).

I addressed these two topics here:
https://gitlab.cee.redhat.com/contra/cnv-qe-automation/-/merge_requests/466

Note that I derived that names of the catalog sources according to the old appregistry namings:
production --> redhat-operators
osbs       --> rh-osbs-operators
stage      --> redhat-operators-stage

please confirm if that's correct for the disconnected clusters you are using.

Thanks

Comment 7 Asher Shoshan 2020-09-23 13:28:08 UTC
(In reply to Oren Cohen from comment #6)
> hi @Inbar,
> 
> The issues @Asher raised were:
> 1. It can be determined if the cluster on which the script is running on, is
> disconnected or not, based on the value of the OperatorHub custom resource,
> and we don't want additional parameter for the script for that.
> 2. The subscription is pointing to a catalog source named
> "hco-catalogsource" which is dynamically created by the kustomize script.
> However, in a disconnected cluster, there is no such catalog source name.
> (the existing catalog sources are not being touched if the cluster is
> disconnected).
> 
> I addressed these two topics here:
> https://gitlab.cee.redhat.com/contra/cnv-qe-automation/-/merge_requests/466
> 
> Note that I derived that names of the catalog sources according to the old
> appregistry namings:
> production --> redhat-operators
> osbs       --> rh-osbs-operators
> stage      --> redhat-operators-stage
> 
> please confirm if that's correct for the disconnected clusters you are using.
> 
> Thanks

Oren,
We can agree these are the names of the catalogs in a disconnected cluster.

Comment 8 Inbar Rose 2020-10-29 11:18:46 UTC
@ashoshan Will this be verified for 2.5.0 or can I target it to 2.5.1?

Comment 10 Simone Tiraboschi 2020-11-02 09:47:02 UTC
Let's postpone to 2.5.1, this is not going to block 2.5.0.

Comment 13 errata-xmlrpc 2020-11-17 13:24:21 UTC
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


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