Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting patchStrategy for maps #12731

Merged
merged 2 commits into from Feb 15, 2017
Merged

Conversation

soltysh
Copy link
Member

@soltysh soltysh commented Jan 31, 2017

This is one possible approach to https://bugzilla.redhat.com/show_bug.cgi?id=1403134

ImageStreamTag allows editing only annotations, but that works only with oc annotate or oc patch command which specifically say what's edited. When oc edit is being invoked it trips over the internal Image object of a IST, due to differences between internal and external representations of this object.
This approach allows setting patchStrategy on struct objects, so they can be ignored, here deleted.

@deads2k || @liggitt does something like that makes sense?
@juanvallejo fyi

@@ -308,7 +308,7 @@ type ImageStreamTag struct {
Conditions []TagEventCondition `json:"conditions,omitempty" protobuf:"bytes,4,rep,name=conditions"`

// Image associated with the ImageStream and tag.
Image Image `json:"image" protobuf:"bytes,5,opt,name=image"`
Image Image `json:"image" patchStrategy:"delete" protobuf:"bytes,5,opt,name=image"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't expect this to do good things. The delete directive is for when you building the patch, not for annotating the type, right? Type annotations are merge or replace as I recall.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are 3 directives from what I see. Although most of the time these are applied only to lists, including delete. Besides, here oc edit ens up producing a patch that is later on submitted to server to modify istag.

@juanvallejo
Copy link
Contributor

cc @liggitt

@mfojtik
Copy link
Member

mfojtik commented Feb 2, 2017

this is must fix for 1.5 (otherwise you can't edit istags ;-)

@liggitt
Copy link
Contributor

liggitt commented Feb 2, 2017

I don't think this is the right approach. See upstream issue kubernetes/kubernetes#20208

Let's coordinate there on what strategic merge patch should do for unknown or unmergeable fields, and see how reasonable it is to pick back to 1.5

@soltysh soltysh force-pushed the bug1403134 branch 3 times, most recently from f50858e to 0d653ca Compare February 8, 2017 13:34
@soltysh
Copy link
Member Author

soltysh commented Feb 8, 2017

@liggitt I'm guessing the approach is approved upstream, only waiting for tests, do you think we can merge this as is upon green tests?

@soltysh
Copy link
Member Author

soltysh commented Feb 8, 2017

[test]

@soltysh
Copy link
Member Author

soltysh commented Feb 8, 2017

Updated the PR with the latest state of upstream PR, waiting for green tests and @liggitt approval

@soltysh
Copy link
Member Author

soltysh commented Feb 8, 2017

Before acceptance we need following tests:

  • modify existing value via edit
  • remove value completely via edit
  • add value from nothing via edit

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to e208952

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/13740/) (Base Commit: 863f435)

@soltysh
Copy link
Member Author

soltysh commented Feb 9, 2017

@liggitt wrt to the tests you've asked for, I can't do any of them, b/c the dockerImageMetadata field is immutable, so none of above the tests make sense. There's one more runtime.RawExtension field in origin, it's objects inside template, but since these are regular k8s objects, and don't have replace patchStrategy set, they don't apply here. I'm still thinking we should have an ignore policy for patch in this particular situation, b/c we're unnecessarily sending the dockerImageMetadata contents in the patch. But that can be solved long term. Let's have this one in, agreed?

@liggitt
Copy link
Contributor

liggitt commented Feb 9, 2017

@liggitt wrt to the tests you've asked for, I can't do any of them, b/c the dockerImageMetadata field is immutable, so none of above the tests make sense

Sorry, I meant as unit tests, upstream. Making sure patch computation can completely remove a raw extension field, add one when missing, and replace one (you already have the last test)

@soltysh
Copy link
Member Author

soltysh commented Feb 9, 2017

Roger that.

@liggitt
Copy link
Contributor

liggitt commented Feb 14, 2017

upstream has LGTM, so this is ready as well

@soltysh
Copy link
Member Author

soltysh commented Feb 14, 2017

@pweil- @mfojtik for approval, this fixes one of my blocker bugs

@mfojtik
Copy link
Member

mfojtik commented Feb 14, 2017

LGTM

(approved for 1.5)

@mfojtik mfojtik added this to the 1.5.0 milestone Feb 14, 2017
@liggitt
Copy link
Contributor

liggitt commented Feb 15, 2017

[merge]

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to e208952

@openshift-bot
Copy link
Contributor

openshift-bot commented Feb 15, 2017

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin_future/246/) (Base Commit: a0ea9b5) (Image: devenv-rhel7_5921)

@openshift-bot openshift-bot merged commit 2a248fb into openshift:master Feb 15, 2017
@soltysh soltysh deleted the bug1403134 branch February 16, 2017 13:44
@mfojtik mfojtik mentioned this pull request Aug 21, 2017
os::cmd::expect_success_and_not_text 'oc get istag/test:new -o jsonpath={.metadata.annotations}' "tags:hidden"
editorfile="$(mktemp -d)/tmp-editor.sh"
echo '#!/bin/bash' > ${editorfile}
echo 'sed -i "s/^tag: null/tag:\n referencePolicy:\n type: Source/g" $1' >> ${editorfile}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@deads2k @mfojtik fyi, it would appear that @soltysh discovered the "you can't update imagestreamtags w/o explicitly adding a reference policy" issue back in february of 2017, but apparently no one cared then.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I knew too much about image streams back then ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants