Description of problem: When "move" action is selected for a glusterfs pvc migration, if there is no OCS4 installed in the target cluster, a PvWarnNoCephAvailable warning is displayed. Version-Release number of selected component (if applicable): TARGET $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.2.0 True False 25h Error while reconciling 4.2.0: the cluster operator marketplace has not yet successfully rolled out SOURCE $ oc version oc v3.11.126 kubernetes v1.11.0+d4cacc0 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https:// openshift v3.9.99 kubernetes v1.9.1+a0ce1bc657 Controller: Version 1.0.1 osbs registry: image: image-registry.openshift-image-registry.svc:5000/rhcam-1-0/openshift-migration-controller-rhel8@sha256:e2c3cbb61157605d8246496f77c76b9b2950eb951bd0a63d4f8e3ae6f1884c2c How reproducible: Always Steps to Reproduce: To reproduce it, we don't actually need to migrate or prepare a cluster for "move" action. We only need to create the migration plan. 1. Install App Migration with target cluster without OCS4 (ceph), and source cluster with OCS3 (gluster) 2. Create a MigPlan of an application using glusterfs volume from source to target, select "move" action. Actual results: After the MigPlan creation, a warning is shown, saying that it's recommended to use OCS4 storage classes, and that it will be used the default storage class instead. Expected results: Destination storage classes don't make much sense talking about "move" action. No warning should be displayed if the selected action is "move" and not "copy". Additional info:
This has been fixed in https://github.com/konveyor/mig-controller/pull/387 It's on both master and the 1.1 release branches.
Verified using CAM 1.2 stage No warnings when "move" action: apiVersion: v1 items: - apiVersion: migration.openshift.io/v1alpha1 kind: MigPlan metadata: annotations: openshift.io/touch: 051270df-9371-11ea-9173-0a580a830007 creationTimestamp: "2020-05-11T10:19:51Z" generation: 5 name: warn namespace: openshift-migration resourceVersion: "55790" selfLink: /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migplans/warn uid: 176cb53e-26e8-441f-9f66-6d3096eee8d0 spec: destMigClusterRef: name: host namespace: openshift-migration migStorageRef: name: automatic namespace: openshift-migration namespaces: - ocp-29871-resquota persistentVolumes: - capacity: 1Gi name: pvc-6034fdf3-9370-11ea-9634-0e2b61783963 pvc: accessModes: - ReadWriteOnce name: nginxapp-logs namespace: ocp-29871-resquota selection: action: move copyMethod: filesystem storageClass: gp2 storageClass: glusterfs-storage supported: actions: - copy - move copyMethods: - filesystem - snapshot - capacity: 1Gi name: pvc-603e0dec-9370-11ea-9634-0e2b61783963 pvc: accessModes: - ReadWriteOnce name: nginxapp-html namespace: ocp-29871-resquota selection: action: move copyMethod: filesystem storageClass: gp2 storageClass: glusterfs-storage supported: actions: - copy - move copyMethods: - filesystem - snapshot srcMigClusterRef: name: source-cluster namespace: openshift-migration status: conditions: - category: Required lastTransitionTime: "2020-05-11T10:19:57Z" message: The `persistentVolumes` list has been updated with discovered PVs. reason: Done status: "True" type: PvsDiscovered - category: Required lastTransitionTime: "2020-05-11T10:19:58Z" message: The storage resources have been created. status: "True" type: StorageEnsured - category: Required lastTransitionTime: "2020-05-11T10:19:59Z" message: The migration registry resources have been created. status: "True" type: RegistriesEnsured - category: Required lastTransitionTime: "2020-05-11T10:19:59Z" message: The migration plan is ready. status: "True" type: Ready observedDigest: ec9935a861266237e33b4de04f6526aa13aec41b9073ac0e5c52d3bef60a6547
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-2020:2326