Bug 1707562

Summary:	Verify installation of CNV via OLM container registry (gRPC catalog source) and subscription/deploy via UI (no marketplace or operatorhub)
Product:	Container Native Virtualization (CNV)	Reporter:	Fabian Deutsch <fdeutsch>
Component:	Installation	Assignee:	Nelly Credi <ncredi>
Status:	CLOSED ERRATA	QA Contact:	Irina Gulina <igulina>
Severity:	high	Docs Contact:
Priority:	high
Version:	2.0	CC:	ashoshan, cnv-qe-bugs, dollierp, dzager, mgoldboi, ncredi, pep, pousley, rhallise
Target Milestone:	---	Keywords:	TestOnly
Target Release:	2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-07-24 20:15:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1711182

Description Fabian Deutsch 2019-05-07 19:26:59 UTC

Description of problem:
Today the following script is used to deploy CNV 2.0 HCO completely via CLI:
https://pkgs.devel.redhat.com/cgit/containers/hco-bundle-registry/plain/qe-testing.sh?h=cnv-2.0-rhel-8

Bu it's unclear how the user is doing it

I'm seeing a few options

a) Document the script for users
b) Deliver the script as a script to users - in an rpm or container
c) Small documentation and UI flow


(a) would look like a mess in it's current form in documentation. If documented, then we need to simplify it drastically

(b) This would involve creating an rpm or container which the user the installs or invokes, which will then launch this script, easier, but requires RCM and build work

(c) IIUIC then only two yamls are needed to register the container registry with OLM and create an operator group, after this has been done a user can use the UI to deploy CNV. The yamls:

```
cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha2
kind: OperatorGroup
metadata:
  name: hco-operatorgroup
  namespace: kubevirt-hyperconverged
---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: hco-catalogsource
  namespace: openshift-operator-lifecycle-manager
  imagePullPolicy: Always
spec:
  sourceType: grpc
  image: $PUBLIC_REGISTRY/container-native-virtualization/hco-bundle-registry:v2.0.0-6
  displayName: KubeVirt HyperConverged
  publisher: Red Hat
EOF
```

I'm in favor of (c) as it embraces the UI, and requires a few doable CLI steps
In addition I'd suggest to provide a kbase with this script for users which want a CLI driven approach.

Comment 1 Ryan Hallisey 2019-05-07 22:55:10 UTC

Option C is where we've been angling towards.  It's a small yaml footprint that we can publish in docs and the UI can handle any wait logic so we don't need a script.  The only concern with C, is we will have two methods to consume operators when we also ship from quay.

Comment 2 Fabian Deutsch 2019-05-07 23:03:05 UTC

Well - I'm afaraid that we'll need to remain both flows anyway, as the container registry seems to align nicely with offline/disconnected installs.

Comment 3 David Zager 2019-05-15 14:37:48 UTC

https://jira.coreos.com/browse/CNV-1591

Comment 5 Fabian Deutsch 2019-05-27 10:44:40 UTC

Nelly, can you please describe the flow you tested (the mixed CLI + UI flow)

Comment 6 Fabian Deutsch 2019-05-27 10:49:05 UTC

*** Bug 1711182 has been marked as a duplicate of this bug. ***

Comment 9 Asher Shoshan 2019-05-27 14:23:43 UTC

We have tested the UI flow of Uninstall/Install CNV (via HCO bundle).

Uninstall is done by 2 steps (must be in this order): Delete the cr of kind "hco", and delete the subscription (+leave the checkbox on the pop-up of csv deletion).

Install is by the reversed steps: create the subscription, and create "hco" cr


Few assumptions here:
1. The catalogsource (hco-catalogsource), and the operatorgroup, both must exist before any UI Uninstall/Install (it has been deployed during the initial deployment script, and it's not documented)
2. above steps Install/Uninstall do not create/remove those resources (catalogsource, operatorgroup).

IMO, operatorgroup creation/removal must be added to Uninstall/Install UI steps (opened a bug for this, and it was closed)

As for the CatalogSource, UI actions (add/delete) must be added to "Operator Management" screen. 
Subscription management should be moved to "installed operators" screen, as it's with specific operator's context.  

Asher

Comment 10 Fabian Deutsch 2019-05-27 18:52:05 UTC

Asher, can you confirm that the installation process works like:

1. CLI: Create operatorgroup and catalogsource with
```
cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha2
kind: OperatorGroup
metadata:
  name: hco-operatorgroup
  namespace: kubevirt-hyperconverged
---
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: hco-catalogsource
  namespace: openshift-operator-lifecycle-manager
  imagePullPolicy: Always
spec:
  sourceType: grpc
  image: $PUBLIC_REGISTRY/container-native-virtualization/hco-bundle-registry:v2.0.0-6
  displayName: KubeVirt HyperConverged
  publisher: Red Hat
EOF
```

2. Web UI: Create subscription, and create HCO CR (pleaase exactly define the UI steps you did).

Comment 18 errata-xmlrpc 2019-07-24 20:15:51 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, 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-2019:1850