Description of problem:

The behaviour of 'oc patch' has changed with OCP 3.9. If a resource does not require patching, 'oc patch' now returns an exit code of 1 instead of 0. We've identified that this does appear to be an intentional change upstream [1]. However the change breaks existing automation of 'oc patch', e.g. its use in ansible or other scripts.

[1] https://github.com/kubernetes/kubernetes/commit/dfef8574cfc71f5b148f3f1d687b50660794b305#diff-def56c6f251836aa7686f7cdc30ce71d

It is of course possible to parse the output of 'oc patch', but the customer behind this bug report feels exiting with 0 would be the appropriate behaviour in this situation.

Also, the change does not appear to be documented in Openshift (or Kubernetes) release notes.

Version-Release number of selected component (if applicable):

oc v3.9.33
kubernetes v1.9.1+a0ce1bc657

How reproducible:

[user@host 39]$ oc create configmap testcm --from-literal=key1=value1
configmap "testcm" created

[user@host 39]$ ./oc version
oc v3.9.33
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://host.example.com:443
openshift v3.9.27
kubernetes v1.9.1+a0ce1bc657

[user@host 39]$ ./oc patch cm testcm -p '{"data":{"key1":"value1"}}'
configmap "testcm" not patched

[user@host 39]$ echo $?
1

[user@host 39]$ cd ../37
[user@host 37]$ ./oc version
oc v3.7.52
kubernetes v1.7.6+a08f5eeb62
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://host.example.com:443
openshift v3.9.27
kubernetes v1.9.1+a0ce1bc657

[user@host 37]$ ./oc patch cm testcm -p '{"data":{"key1":"value1"}}'
configmap "testcm" not patched

[user@host 37]$ echo $?
0

Actual results:

oc patch exits with code 1 in case resource doesn't need patching

Expected results:

oc patch exits with code 0 in case resource doesn't need patching