Bug 2207780

Summary: Volume Replication object is editable after it is created while it should not be
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Yuli Persky <ypersky>
Component: ocs-operatorAssignee: Nikhil Ladha <nladha>
Status: ASSIGNED --- QA Contact: Elad <ebenahar>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: kramdoss, mrajanna, muagarwa, ngowda, odf-bz-bot, rar
Target Milestone: ---Keywords: Automation
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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:
Bug Depends On:    
Bug Blocks: 2005835    

Description Yuli Persky 2023-05-16 20:38:31 UTC
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:

Comment 3 Yuli Persky 2023-05-17 20:55:38 UTC
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/

Comment 5 Yuli Persky 2023-05-28 23:35:58 UTC
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/.

Comment 7 Yuli Persky 2023-05-29 09:53:09 UTC
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/
.

Comment 9 Yuli Persky 2023-05-29 20:00:51 UTC
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.

Comment 10 Mudit Agarwal 2023-05-30 11:25:19 UTC
Moving to 4.14 as per the decision, more details are on the epic Jira https://issues.redhat.com/browse/RHSTOR-3863

Comment 14 Nitin Goyal 2023-08-08 07:41:03 UTC
Moving it to 4.15, I belive the component should be csi-addons.