Hide Forgot
Description of problem: When we use --dry-run=server with oc commands, then it means to submit the server-side requests without persisting the resource. However, when we tried to modify the config maps/secrets using --dry-run=server, the changes were made persistently. Version-Release number of selected component (if applicable): RHOCP v4.7.37 How reproducible: I have tried to reproduce the same on my test cluster and I have tested it on config maps and secrets. The results are the same. Steps to Reproduce: 1.$ oc create configmap cm-testing --from-literal=name=abc configmap/cm-testing created $ oc get cm cm-testing -oyaml ~~~ apiVersion: v1 data: name: abc kind: ConfigMap metadata: creationTimestamp: "2021-12-16T02:55:19Z" name: cm-testing namespace: mridul resourceVersion: "4973134" uid: 0f0a1052-059d-49f2-95e8-e8fad775161b ~~~ 2.[ When used dry-run=client ] $ oc set data cm/cm-testing --from-literal=name=def --dry-run=client configmap/cm-testing data updated (dry run) You have new mail in /var/spool/mail/quicklab $ oc get cm cm-testing -oyaml ~~~ apiVersion: v1 data: name: abc kind: ConfigMap metadata: creationTimestamp: "2021-12-16T02:55:19Z" name: cm-testing namespace: mridul resourceVersion: "4973134" uid: 0f0a1052-059d-49f2-95e8-e8fad775161b ~~~ 3. [ When used dry-run=server ] $ oc set data cm/cm-testing --from-literal=name=def --dry-run=server configmap/cm-testing data updated (server dry run) $ oc get cm cm-testing -oyaml ~~~ apiVersion: v1 data: name: def >>>>>>>>>>>>>>>>>>>> The data changes persistently kind: ConfigMap metadata: creationTimestamp: "2021-12-16T02:55:19Z" name: cm-testing namespace: mridul resourceVersion: "4975721" uid: 0f0a1052-059d-49f2-95e8-e8fad775161b ~~~ Actual results: The data of the config map changed persistently when used --dry-run=server. Expected results: The data should not get changed persistently. Additional info: I have tested the same on the secrets resource and as specified above, the secret data also got modified on the fly.
Hello Team, There is one more update that I would like to share with you. The customer also tested the same on RHCOP v4.8 and the same bug exists there as well, which we have to fix. ~~~ Client Version: 4.8.0-202111041632.p0.git.88e7eba.assembly.stream-88e7eba Server Version: 4.8.24 ~~~ Regards, Mridul Markandey
Confirmed with latest oc , the issue can't reproduce now: [root@localhost ~]# oc version --client Client Version: 4.10.0-202201041327.p0.g080f0de.assembly.stream-080f0de [root@localhost ~]# oc get cm cm-testing -o yaml apiVersion: v1 data: name: abc kind: ConfigMap metadata: creationTimestamp: "2022-01-06T02:33:57Z" name: cm-testing namespace: test1 resourceVersion: "77236" uid: 995b4044-4375-4796-83f5-f3bd72bc3331 [root@localhost ~]# oc set data cm/cm-testing --from-literal=name=def --dry-run=client configmap/cm-testing data updated (dry run) [root@localhost ~]# oc get cm cm-testing -o yaml apiVersion: v1 data: name: abc kind: ConfigMap metadata: creationTimestamp: "2022-01-06T02:33:57Z" name: cm-testing namespace: test1 resourceVersion: "77236" uid: 995b4044-4375-4796-83f5-f3bd72bc3331 [root@localhost ~]# oc set data cm/cm-testing --from-literal=name=def --dry-run=server configmap/cm-testing data updated (server dry run) [root@localhost ~]# oc get cm cm-testing -o yaml apiVersion: v1 data: name: abc kind: ConfigMap metadata: creationTimestamp: "2022-01-06T02:33:57Z" name: cm-testing namespace: test1 resourceVersion: "77236" uid: 995b4044-4375-4796-83f5-f3bd72bc3331 [root@localhost ~]# oc create secret generic my-secret --from-literal=key1=supersecret secret/my-secret created [root@localhost ~]# oc get secret my-secret -o yaml apiVersion: v1 data: key1: c3VwZXJzZWNyZXQ= kind: Secret metadata: creationTimestamp: "2022-01-06T02:40:56Z" name: my-secret namespace: test1 resourceVersion: "79412" uid: c9f25d0f-85b0-4b9f-99fe-6f94f61f95f7 type: Opaque [root@localhost ~]# oc set data secret/my-secret --from-literal=key1=testset --dry-run='client' secret/my-secret data updated (dry run) [root@localhost ~]# oc get secret my-secret -o yaml apiVersion: v1 data: key1: c3VwZXJzZWNyZXQ= kind: Secret metadata: creationTimestamp: "2022-01-06T02:40:56Z" name: my-secret namespace: test1 resourceVersion: "79412" uid: c9f25d0f-85b0-4b9f-99fe-6f94f61f95f7 type: Opaque [root@localhost ~]# oc set data secret/my-secret --from-literal=key1=testset --dry-run='server' secret/my-secret data updated (server dry run) [root@localhost ~]# oc get secret my-secret -o yaml apiVersion: v1 data: key1: c3VwZXJzZWNyZXQ= kind: Secret metadata: creationTimestamp: "2022-01-06T02:40:56Z" name: my-secret namespace: test1 resourceVersion: "79412" uid: c9f25d0f-85b0-4b9f-99fe-6f94f61f95f7 type: Opaque
Hello Team, As this Bugzilla is going to be resolved for OpenShift version 4.10, So do you have any information if this will be backported to OCPv4.9 and OCP v4.8? Appreciate your quick response. --- Regards, Mridul Markandey
(In reply to Mridul Markandey from comment #6) > Hello Team, > > As this Bugzilla is going to be resolved for OpenShift version 4.10, So do > you have any information if this will be backported to OCPv4.9 and OCP v4.8? Yes, backports are on the way, see the list of blocked bugzillas linked to this.