-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
4.18.z, 4.19.z
-
None
-
Quality / Stability / Reliability
-
False
-
-
None
-
Important
-
None
-
All
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
The upgrade from Openshift 4.18.z to 4.19 cannot proceed until users enter a complex oc command to confirm they know the 4.18 cluster does not use any of the removed APIs. Here is the command, documented in KCS https://access.redhat.com/articles/7112216
$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"' --type=merge}}
The command works as expected from Linux oc, but fails with an obscure syntax error with Windows oc. Other oc commands may also have the same problem.
Version-Release number of selected component (if applicable):
4.y
How reproducible:
at will
Steps to Reproduce:
1. From a Windows CMD window, oc login to the Openshift cluster of interest.
2. Issue the command above.
3.
Actual results:
C:\Users\gregs\Downloads\oc>oc version
Client Version: 4.18.0-202506241202.p0.g04e91ac.assembly.stream.el9-04e91ac
Kustomize Version: v5.4.2
Server Version: 4.19.3
Kubernetes Version: v1.32.5C:\Users\gregs\Downloads\oc>
C:\Users\gregs\Downloads\oc>oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"}}' --type=merge
Error from server (BadRequest): error decoding patch: json: cannot unmarshal string into Go value of type map[string]interface {}
It works fine from Linux.
[gregs@storage2015 Downloads]$ ./oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.18-kube-1.32-api-removals-in-4.19":"true"}}' --type=merge
configmap/admin-acks patched
[gregs@storage2015 Downloads]$
Expected results:
Oc commands should execute on Windows without generating ugly syntax errors. If there are syntax differences between Windows and Linux, we should document them.
Additional info:
I tried escaping every combination of quotes I could think of. Nothing I tried made a difference.
I am logging a bug on this specific command, but this may turn into a can of worms with syntax differences between Windows and Linux. If users need to escape certain characters in Windows or make other adjustments, we should document that.
