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.
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.
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.
https://jira.coreos.com/browse/CNV-1591
Nelly, can you please describe the flow you tested (the mixed CLI + UI flow)
*** Bug 1711182 has been marked as a duplicate of this bug. ***
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
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).
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