Bug 1966455 - Default storage class disappears from storage class list on Copy Options screen after namespace mapping is edited in migration plan
Summary: Default storage class disappears from storage class list on Copy Options scre...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Migration Toolkit for Containers
Classification: Red Hat
Component: General
Version: 1.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 1.5.0
Assignee: Ian
QA Contact: Xin jiang
Avital Pinnick
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-01 08:27 UTC by Sergio
Modified: 2021-07-28 04:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-28 04:08:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github konveyor mig-ui pull 1236 0 None open Bug 1966455: Default to current selected if no selection is made 2021-06-18 13:27:58 UTC
Github konveyor mig-ui pull 1237 0 None open Bug 1966455: fix sc selection bug 2021-06-18 13:56:23 UTC
Red Hat Product Errata RHEA-2021:2929 0 None None None 2021-07-28 04:08:15 UTC

Description Sergio 2021-06-01 08:27:46 UTC
Description of problem:
When we create a migration plan, and we click on "back" to edit the migration plan destination name, the default storage class is not shown any more.

Version-Release number of selected component (if applicable):
MTC 1.5.0
TARGET CLUSTER: AWS OCP 4.8 (gp2)
SOURCE CLUSTER: AWS OCP 3.11 (gp2)
REPLICATION REPOSITORY: AWS S3

How reproducible:
Always

Steps to Reproduce:
1. Deploy a sample django application
 $ oc new-project bz-test
 $ oc new-app django-psql-persistent

2. Click on "Add migration plan" in the migration plans screen
3. Fill in the form: name, source cluster, destination cluster and replication repository
4. Check the bz-test namespace (do NOT map the namespace to another name) and click "Next"

Once the PVCs are discovered we have this information in the migplan
  namespaces:
  - bz-test
  persistentVolumes:
  - capacity: 1Gi
    name: pvc-69a1dd43-c21c-11eb-a9dd-0eeaed03c931
    proposedCapacity: 1Gi
    pvc:
      accessModes:
      - ReadWriteOnce
      hasReference: true
      name: postgresql
      namespace: bz-test
    selection:
      action: copy
      copyMethod: filesystem
      storageClass: gp2


5. Click on "Back", in order to edit the namespace mapping
7. Click on the pencil icon, and map the namespace to the new name bz-test-map. Save the change clicking on the "V" symbol and click on "Next"

Once the PVCs have been discovered again, we have this information in the migplan

  namespaces:
  - bz-test:bz-test-map
  persistentVolumes:
  - capacity: 1Gi
    name: pvc-69a1dd43-c21c-11eb-a9dd-0eeaed03c931
    proposedCapacity: 1Gi
    pvc:
      accessModes:
      - ReadWriteOnce
      hasReference: true
      name: postgresql
      namespace: bz-test
    selection:
      action: copy
      copyMethod: filesystem
      storageClass: ""
      verify: false
    storageClass: gp2

8. Click on "Next"

Actual results:
The "Copy options" screen does not show the default storage class. The value shown for the storage class is "None", instead of the "gp2" value that should be displayed.

The information that we get in the migplan at this point is this:

  namespaces:
  - bz-test:bz-test-map
  persistentVolumes:
  - capacity: 1Gi
    name: pvc-69a1dd43-c21c-11eb-a9dd-0eeaed03c931
    proposedCapacity: 1Gi
    pvc:
      accessModes:
      - ReadWriteOnce
      hasReference: true
      name: postgresql
      namespace: bz-test
    selection:
      action: copy
      copyMethod: filesystem
    storageClass: gp2


We can notice that the selection.storageclass value is missing from the yaml information.

Expected results:
The default storage class should be displayed in the "Copy options" screen. And the data in the migplan yaml information should be the right one, including the default storage class. 

Additional info:

Comment 1 Derek Whatley 2021-06-11 15:23:01 UTC
It's possible this is a controller issue, but can't be sure without further investigation.

Comment 6 whu 2021-06-24 11:56:10 UTC
Verified against MTC 1.5.0 stage image: 
registry.stage.redhat.io/rhmtc/openshift-migration-rhel7-operator@sha256:17d819f0c28828bc5095bf917563388e05144e2bbbe9c0c86810b350425ee341

the migplan after step 4

    name: pvc-e45f86d9-d4e1-11eb-a216-0e54478c512f
    proposedCapacity: 32517M
    pvc:
      accessModes:
      - ReadWriteOnce
      hasReference: true
      name: nginx-html-012345678901234567890123456789012345678901234567890123456789
      namespace: ocp-11111-nginx
    selection:
      action: copy
      copyMethod: filesystem
      storageClass: nfs
    storageClass: nfs
    supported:
      actions:
      - copy
      - move
      copyMethods:
      - filesystem
      - snapshot


the migplan after step 7

    name: pvc-e45f86d9-d4e1-11eb-a216-0e54478c512f
    proposedCapacity: 32517M
    pvc:
      accessModes:
      - ReadWriteOnce
      hasReference: true
      name: nginx-html-012345678901234567890123456789012345678901234567890123456789
      namespace: ocp-11111-nginx
    selection:
      action: copy
      copyMethod: filesystem
      storageClass: nfs
    storageClass: nfs
    supported:
      actions:
      - copy
      - move
      copyMethods:
      - filesystem
      - snapshot

Comment 12 errata-xmlrpc 2021-07-28 04:08: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 (Migration Toolkit for Containers (MTC) image release advisory 1.5.0), 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-2021:2929


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