Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1813462

Summary: NooBaa/MCG tasks fail in non-olm installs due to missing CRDs
Product: OpenShift Container Platform Reporter: Jason Montleon <jmontleo>
Component: Migration ToolingAssignee: Jason Montleon <jmontleo>
Status: CLOSED ERRATA QA Contact: Xin jiang <xjiang>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.3.0CC: chezhang, dymurray, sregidor, whu
Target Milestone: ---   
Target Release: 4.3.z   
Hardware: Unspecified   
OS: Unspecified   
URL: https://github.com/konveyor/mig-operator/pull/262
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-23 17:26:07 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:

Description Jason Montleon 2020-03-13 21:18:56 UTC 
Description of problem:
NooBaa/MCG tasks fail in non-olm installs due to missing CRDs

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

How reproducible:
Always

Steps to Reproduce:
1. Perform a non-OLM install without controller or UI
2. Check logs in the operator

Actual results:
MCG tasks are failing

Expected results:
MCG tasks succeed

Additional info:
In reality since the MCG tasks are after everything else and we're not yet advertising MCG support this is ugly but not breaking much. The answer is to always install the CRDs on nonOLM installs regardless of the components selected just as would happen with OLM.
Comment 2 Jason Montleon 2020-03-17 12:57:10 UTC 
1.1 refers to CAM. 

This bug is also referring to CAMs mig* CRDs. We have a task related to installing NooBaa in our operator that is looking for a migstorage CR and if the CRD is not present it causes a task failure.

There is no need to install NooBaa since the task runs even if NooBaa features are not enabled, in order to clean up.

To confirm the bug is fixed (I believe it is in upstream latest, but not 1.1 up or downstream at present) all you have to do is install the operator using the non-olm method on a never before used cluster without the controller or ui, confirm that the mig* crd's are installed, and that the operator ansible pod is showing all tasks completing without failure.
Comment 3 Dylan Murray 2020-03-17 21:32:16 UTC 
https://github.com/konveyor/mig-operator/commit/e228055efdfa704f880ddcfc4f6a8d88ca93bfee

Fix is here.
Comment 4 Dylan Murray 2020-03-17 23:31:51 UTC 
Operator build: openshift-migration-operator-container-v1.1-9
Comment 7 whu 2020-03-25 10:25:30 UTC 
Verified in CAM 1.1.2 stage

[operator information]
imageID: docker-pullable://quay-enterprise-quay-enterprise.apps.qe-appmig-tgt-980.qe.devcluster.openshift.com/admin/openshift-migration-rhel7-operator@sha256:b3c49fce01e386fae978044ddbdab7bbcb8b140846d4b97488b8e139c4f3e73b


$ oc logs pod/migration-operator-9fb87db69-w77kx  -n openshift-migration -c ansible
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/tmp/ansible-operator/runner/migration.openshift.io/v1alpha1/MigrationController/openshift-migration/migration-controller/artifacts/8674665223082153551//stdout
ansible-playbook 2.8.8
......................
TASK [migrationcontroller : Creating NooBaa backed migstorage] *****************
task path: /opt/ansible/roles/migrationcontroller/tasks/mcg.yml:152
skipping: [localhost] => {"changed": false, "skip_reason": "Conditional result was False"}
META: ran handlers
META: ran handlers

PLAY RECAP *********************************************************************
localhost                  : ok=27   changed=7    unreachable=0    failed=0    skipped=71   rescued=0    ignored=0   



$ oc get crd
NAME                                          CREATED AT
alertmanagers.monitoring.coreos.com           2020-03-25T06:00:05Z
backups.velero.io                             2020-03-25T10:20:09Z
backupstoragelocations.velero.io              2020-03-25T10:20:09Z
bundlebindings.automationbroker.io            2020-03-25T06:04:00Z
bundleinstances.automationbroker.io           2020-03-25T06:04:02Z
bundles.automationbroker.io                   2020-03-25T06:04:03Z
deletebackuprequests.velero.io                2020-03-25T10:20:09Z
downloadrequests.velero.io                    2020-03-25T10:20:09Z
migclusters.migration.openshift.io            2020-03-25T10:20:13Z
migmigrations.migration.openshift.io          2020-03-25T10:20:15Z
migplans.migration.openshift.io               2020-03-25T10:20:17Z
migrationcontrollers.migration.openshift.io   2020-03-25T10:12:02Z
migstorages.migration.openshift.io            2020-03-25T10:20:18Z
podvolumebackups.velero.io                    2020-03-25T10:20:09Z
podvolumerestores.velero.io                   2020-03-25T10:20:09Z
prometheuses.monitoring.coreos.com            2020-03-25T06:00:05Z
prometheusrules.monitoring.coreos.com         2020-03-25T06:00:05Z
resticrepositories.velero.io                  2020-03-25T10:20:09Z
restores.velero.io                            2020-03-25T10:20:09Z
schedules.velero.io                           2020-03-25T10:20:09Z
serverstatusrequests.velero.io                2020-03-25T10:20:09Z
servicemonitors.monitoring.coreos.com         2020-03-25T06:00:05Z
volumesnapshotlocations.velero.io             2020-03-25T10:20:09Z
Comment 9 errata-xmlrpc 2020-04-23 17:26:07 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/RHBA-2020:1554