Red Hat Bugzilla – Bug 1609179
oc patch returns return code 1 if resource does not need patching
Last modified: 2018-10-11 03:22:46 EDT
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
The issue comes from the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1311786
It seems the patch code would need to differentiate between multiple conditions leading to a 'not patched' result [1]. 1. nothing was patched because resource did not need patching -> exit code 0 2. nothing was patched because the patch wasn't valid, or because of some other error -> exit code 1 [1] https://access.redhat.com/solutions/3345621
Upstream PR: https://github.com/kubernetes/kubernetes/pull/66725 This patch slightly alters the behavior of the "patch" command to reflect the following scenarios: 1. nothing was patched because the resource did not need patching -> "<object> not patched" and "exit code 0" 2. nothing was patched because the patch was invalid or due to an unexpected error -> "<object> not patched" and "exit code 1" 3. any other case -> "<object> patched" and "exit code 0"
Origin PR: https://github.com/openshift/origin/pull/20456
https://github.com/openshift/origin/pull/20456 has merged. Moving to MODIFIED
Verified in v3.11.0-0.22.0, the result is same as comment 4
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2652