Description of problem (please be detailed as possible and provide log snippests): PVC name ( spec => name) and volumeReplicationClass can be edited successfully in VolumeReplication object after it is created. Version of all relevant components (if applicable): OCS versions ============== NAME DISPLAY VERSION REPLACES PHASE mcg-operator.v4.13.0-157.stable NooBaa Operator 4.13.0-157.stable Succeeded ocs-operator.v4.13.0-157.stable OpenShift Container Storage 4.13.0-157.stable Succeeded odf-csi-addons-operator.v4.13.0-157.stable CSI Addons 4.13.0-157.stable Succeeded odf-operator.v4.13.0-157.stable OpenShift Data Foundation 4.13.0-157.stable Succeeded ODF (OCS) build : full_version: 4.13.0-157 Rook versions =============== rook: v4.13.0-0.dcb0f9119dcfecb7256321eea60c54ec5f010959 go: go1.19.6 Ceph versions =============== ceph version 17.2.5-1342.el9cp (ed07851f2c5b8d3dccadf079402f86a67cb7d3e5) quincy (stable) OCP versions ============== clientVersion: buildDate: "2023-04-19T04:06:40Z" compiler: gc gitCommit: 92b1a3d0e5d092430b523f6541aa0c504b2222b3 gitTreeState: clean gitVersion: 4.13.0-202304190216.p0.g92b1a3d.assembly.stream-92b1a3d goVersion: go1.19.6 major: "" minor: "" platform: linux/amd64 kustomizeVersion: v4.5.7 openshiftVersion: 4.13.0-0.nightly-2023-04-11-144406 releaseClientVersion: 4.13.0-0.nightly-2023-05-04-090524 serverVersion: buildDate: "2023-04-06T14:21:00Z" compiler: gc gitCommit: 0cffe665612c2b8ac54f19c932b33e84261992d9 gitTreeState: clean gitVersion: v1.26.2+22308ca goVersion: go1.19.6 major: "1" minor: "26" platform: linux/amd64 Cluster version: NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.13.0-0.nightly-2023-04-11-144406 True False 25d Cluster version is 4.13.0-0.nightly-2023-04-11-144406 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? Is there any workaround available to the best of your knowledge? No Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 3 Can this issue reproducible? Yes Can this issue reproduce from the UI? If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. Create VolumeReplication using the following yaml file: apiVersion: replication.storage.openshift.io/v1alpha1 kind: VolumeReplication metadata: name: volume-replication-sample namespace: default spec: volumeReplicationClass: volumereplicationclass-sample replicationState: primary autoResync: false dataSource: kind: PersistentVolumeClaim name: myPersistentVolumeClaim Result - the following object is created : apiVersion: replication.storage.openshift.io/v1alpha1 kind: VolumeReplication metadata: creationTimestamp: "2023-05-16T10:29:38Z" generation: 5 name: volume-replication-sample namespace: default resourceVersion: "36375194" uid: e7f43a29-52e7-4b45-a9c2-d365c5d7c8c0 spec: autoResync: false dataSource: kind: PersistentVolumeClaim name: myPersistentVolumeClaimyulipersky replicationState: primary volumeReplicationClass: volumereplicationclass-sample11111111 status: conditions: - lastTransitionTime: "2023-05-16T10:29:38Z" message: "" observedGeneration: 5 reason: FailedToPromote status: "False" type: Completed - lastTransitionTime: "2023-05-16T10:29:38Z" message: "" observedGeneration: 5 reason: Error status: "True" type: Degraded - lastTransitionTime: "2023-05-16T10:29:38Z" message: "" observedGeneration: 5 reason: NotResyncing status: "False" type: Resyncing message: VolumeReplicationClass.replication.storage.openshift.io "volumereplicationclass-sample11111111" not found observedGeneration: 5 state: Unknown 2.Edit the object that was created each time edit only one out of the two fields : name in spec section, volumeReplicationClass in spec section 3. Actual results: Each one of the above fields is editable after creation, while it should not be. Expected results: name and VolumeReplocationClass should not be editable. Additional info:
I've reproduced the problem again on my cluster and collected must gather logs which are available here : rhsqe-repo.lab.eng.blr.redhat.com:/var/www/html/OCS/ocs-qe-bugs/bz-2207780/
It seems that The problem is persistent. The eteps I've performed : 1) I've deployed a cluster ( cluster name ypersky-c13, https://ocs4-jenkins-csb-odf-qe.apps.ocp-c1.prod.psi.redhat.com/job/qe-deploy-ocs-cluster/24752/ ) with the following versions: OCP versions ============== clientVersion: buildDate: "2023-04-19T04:06:40Z" compiler: gc gitCommit: 92b1a3d0e5d092430b523f6541aa0c504b2222b3 gitTreeState: clean gitVersion: 4.13.0-202304190216.p0.g92b1a3d.assembly.stream-92b1a3d goVersion: go1.19.6 major: "" minor: "" platform: linux/amd64 kustomizeVersion: v4.5.7 openshiftVersion: 4.13.0-0.nightly-2023-05-22-040653 releaseClientVersion: 4.13.0-0.nightly-2023-05-18-013939 serverVersion: buildDate: "2023-04-19T02:20:48Z" compiler: gc gitCommit: 9ded806a7d5deed41a20f680cf89dae58bbb5697 gitTreeState: clean gitVersion: v1.26.3+b404935 goVersion: go1.19.6 major: "1" minor: "26" platform: linux/amd64 Cluster version: NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.13.0-0.nightly-2023-05-22-040653 True False 5d23h Cluster version is 4.13.0-0.nightly-2023-05-22-040653 2) I've created a pvc : yuli-test-pvc - 1 GB pvc in default namespace, the yaml output after creation is : kind: PersistentVolumeClaim apiVersion: v1 metadata: name: yuli-test-pvc namespace: default uid: ed7a31b2-aa0c-43a7-a00d-6bcfc8fea169 resourceVersion: '2044227' creationTimestamp: '2023-05-25T14:25:35Z' annotations: pv.kubernetes.io/bind-completed: 'yes' pv.kubernetes.io/bound-by-controller: 'yes' volume.beta.kubernetes.io/storage-provisioner: openshift-storage.rbd.csi.ceph.com volume.kubernetes.io/storage-provisioner: openshift-storage.rbd.csi.ceph.com finalizers: - kubernetes.io/pvc-protection managedFields: - manager: Mozilla operation: Update apiVersion: v1 time: '2023-05-25T14:25:35Z' fieldsType: FieldsV1 fieldsV1: 'f:spec': 'f:accessModes': {} 'f:resources': 'f:requests': .: {} 'f:storage': {} 'f:storageClassName': {} 'f:volumeMode': {} - manager: kube-controller-manager operation: Update apiVersion: v1 time: '2023-05-25T14:25:35Z' fieldsType: FieldsV1 fieldsV1: 'f:metadata': 'f:annotations': .: {} 'f:pv.kubernetes.io/bind-completed': {} 'f:pv.kubernetes.io/bound-by-controller': {} 'f:volume.beta.kubernetes.io/storage-provisioner': {} 'f:volume.kubernetes.io/storage-provisioner': {} 'f:spec': 'f:volumeName': {} - manager: kube-controller-manager operation: Update apiVersion: v1 time: '2023-05-25T14:25:35Z' fieldsType: FieldsV1 fieldsV1: 'f:status': 'f:accessModes': {} 'f:capacity': .: {} 'f:storage': {} 'f:phase': {} subresource: status spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi volumeName: pvc-ed7a31b2-aa0c-43a7-a00d-6bcfc8fea169 storageClassName: ocs-storagecluster-ceph-rbd volumeMode: Filesystem status: phase: Bound accessModes: - ReadWriteOnce capacity: storage: 1Gi 3) I've created a VR with the following yaml file: apiVersion: replication.storage.openshift.io/v1alpha1 kind: VolumeReplication metadata: name: volume-replication-sample namespace: default spec: volumeReplicationClass: volumereplicationclass-sample replicationState: primary autoResync: false dataSource: kind: PersistentVolumeClaim name: yuli-test-pvc Result: The VR was created : [ypersky@ypersky ocs-ci]$ oc create -f /home/ypersky/ypersky-yaml/ypersky-csi/VR_test.yaml volumereplication.replication.storage.openshift.io/volume-replication-sample created 4) I've edited volumereplication.replication.storage.openshift.io/volume-replication-sample ( changed PVC name ( spec => name) and volumeReplicationClass). And those were successfully edited. You are welcome to take a loot at ypersky-c13 : https://ocs4-jenkins-csb-odf-qe.apps.ocp-c1.prod.psi.redhat.com/job/qe-deploy-ocs-cluster/24752/.
In addition to comment#5 - the must gather logs were collected and are located in rhsqe-repo.lab.eng.blr.redhat.com:/var/www/html/OCS/ocs-qe-bugs/bz-2207780/ .
Reproduction instructions: 1) Create a pvc in default namespace ( or any other different from openshift-storage namespace) 2) Create VR for the pvc created in 1 ( edit the relevant yaml file with the correct pvc name) 3) Edit pvc name / VRC in the created VR object => it should NOT be editable.
Moving to 4.14 as per the decision, more details are on the epic Jira https://issues.redhat.com/browse/RHSTOR-3863
Moving it to 4.15, I belive the component should be csi-addons.