This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 2207780 - Volume Replication object is editable after it is created while it should not be
Summary: Volume Replication object is editable after it is created while it should not be
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat OpenShift Data Foundation
Classification: Red Hat Storage
Component: csi-addons
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ODF 4.15.0
Assignee: Madhu Rajanna
QA Contact: Yuli Persky
URL:
Whiteboard:
Depends On:
Blocks: 2005835
TreeView+ depends on / blocked
 
Reported: 2023-05-16 20:38 UTC by Yuli Persky
Modified: 2024-01-11 12:24 UTC (History)
8 users (show)

Fixed In Version: 4.15.0-91
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-01-05 14:27:29 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github csi-addons kubernetes-csi-addons pull 459 0 None Merged use CEL for CR validation 2023-10-04 11:26:47 UTC
Github red-hat-storage kubernetes-csi-addons pull 89 0 None Merged Sync the upstream changes from `csi-addons/kubernetes-csi-addons:main` into the `main` branch 2023-11-10 15:57:25 UTC
Red Hat Issue Tracker   RHSTOR-3903 0 None None None 2024-01-11 12:24:17 UTC

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.

Comment 17 Niels de Vos 2023-10-04 11:26:47 UTC
https://github.com/csi-addons/kubernetes-csi-addons/pull/459 has been merged for upstream. Once the downstream component is rebased for ODF-4.15 the fix will be included.

Comment 18 Niels de Vos 2023-11-10 15:57:26 UTC
Downstream PR that syncs the change into the release-4.15 branch: https://github.com/red-hat-storage/kubernetes-csi-addons/pull/89

Comment 23 Niels de Vos 2024-01-05 14:27:29 UTC
This is parh of a larger ODF-4.15 feature, which is tracked and verified through Jira.


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