Bug 1267454 - It's better to show additional prompt when 'oc patch' non-existing fields of resource
Summary: It's better to show additional prompt when 'oc patch' non-existing fields of ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: David Eads
QA Contact: Wei Sun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-30 05:56 UTC by Xingxing Xia
Modified: 2020-02-26 19:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-26 19:10:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1311786 0 medium CLOSED oc patch reports success with incorrect patch information 2022-08-29 10:13:51 UTC
Red Hat Bugzilla 1409225 0 unspecified CLOSED cannot patch a value to empty string 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1466664 0 unspecified CLOSED oc patch dc reports dc changed even if no changes made 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1466671 0 medium CLOSED oc patch always returns "patched" even if it doesn't do anything 2021-03-03 14:17:52 UTC

Internal Links: 1311786 1409225 1466664 1466671

Description Xingxing Xia 2015-09-30 05:56:15 UTC
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

Comment 1 David Eads 2015-09-30 16:06:38 UTC
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.

Comment 2 Xingxing Xia 2017-01-05 03:07:12 UTC
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"

Comment 3 Xingxing Xia 2017-06-30 10:52:11 UTC
Again, occurrences of similar confusion appear in bug 1466671 and bug 1466664


Note You need to log in before you can comment on or make changes to this bug.