Description of problem: When apply 'oc patch' to update resource with fields that are non-existing, i.e. not defined by the resource specification, the result should give prompt, telling us the patch doesn't take effect. Version-Release number of selected component (if applicable): openshift v1.0.6-266-gcfbe4fb oc v1.0.6-266-gcfbe4fb kubernetes v1.1.0-alpha.1-653-g86b4e77 How reproducible: Always Steps to Reproduce: 1.Launch openshift 2.Login, create a project and create applications 3.Use oc patch to update non-existing fields to resource 1 > Check dc resource $ oc get dc 2> $ oc patch dc database -p '{"nothisfield": {"replicas": 2}}' 3> $ oc get dc/database -t '{{ .nothisfield }}' | grep '.' Actual results: 3. 2> "database" patched 3> In fact, we can see it is not patched <no value> Expected results: 3. 2> We suggest the output give prompt, like: patch canceled, no changes made 3> <no value> Additional info: If do not give prompt, then operation mistake may be omitted. e.g. I intend to patch dc, but mistakenly apply it to bc: oc patch bc ruby-sample-build -p '{"spec": {"replicas": 2}}' But the result is it is patched
This is a more general problem with CLI mutations not validating their changes. Create, edit, and update have this same problem when specifying fields that don't exist. I suspect that this will remain as a limitation for some time. Adding Jordan and Clayton so they have a chance to disagree.
https://bugzilla.redhat.com/show_bug.cgi?id=1409225#c3 Singular "annotation" in bug 1409925 is kind of not-existing field which causes UX problem and makes user confusion because of the prompt "... patched"
Again, occurrences of similar confusion appear in bug 1466671 and bug 1466664