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

explicitly prohibit updates to imagestream tags that are not spec tags #18532

Merged
merged 1 commit into from
Mar 7, 2018

Conversation

bparees
Copy link
Contributor

@bparees bparees commented Feb 8, 2018

fixes #18519

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Feb 8, 2018
@bparees
Copy link
Contributor Author

bparees commented Feb 8, 2018

@smarterclayton @deads2k ptal

the net effect of this is that if you edit an IST that was only pushed, the update results in adding a new spec tag to the IS:

spec:
  lookupPolicy:
    local: false
  tags:
  - annotations:
      foo: bar
    generation: 2
    importPolicy: {}
    name: latest
    referencePolicy:
      type: Source

Which near as i can tell is absolutely required because that's where the annotations are stored, so you can't add annotations w/o introducing a spec tag.

I would certainly rather this go through the mainline defaulting logic instead of what i'm doing, but it sounds like that might not be a realistic option.

@bparees
Copy link
Contributor Author

bparees commented Feb 8, 2018

(the other option is that we just say "you shouldn't be updating ISTs that were only pushed, the current behavior is acceptable")

@deads2k
Copy link
Contributor

deads2k commented Feb 8, 2018

I don't actually know how other clients will interpret this. Without an import policy, it doesn't sound that bad.

@bparees
Copy link
Contributor Author

bparees commented Feb 12, 2018

@smarterclayton bump

@bparees
Copy link
Contributor Author

bparees commented Feb 14, 2018

one bad thing about this: since "From" is empty, it results in rather user unfriendly errors when you run "oc import-image", e.g.:

error: the tag "latest" does not exist on the image stream - choose an existing tag to import or use the 'tag' command to create a new tag

Clearly having a spec.tag with an empty "From" is not handled well by oc import-image. So this may not be the right solution. (In theory i could also craft the "From" value to point to the internal registry, but that seems a bit dubious)

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 14, 2018
@bparees bparees changed the title default reference policy when updating an imagestreamtag explicitly prohibit updates to imagestream tags that are not spec tags Feb 14, 2018
@bparees
Copy link
Contributor Author

bparees commented Feb 14, 2018

@deads2k @smarterclayton ok i've reworked this to just reject the update w/ a clean message telling you why your imagestreamtag update is being rejected. ptal again.

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 14, 2018
@bparees
Copy link
Contributor Author

bparees commented Feb 19, 2018

/retest

@bparees
Copy link
Contributor Author

bparees commented Feb 26, 2018

@smarterclayton bump

@bparees
Copy link
Contributor Author

bparees commented Mar 1, 2018

implicit approval from @smarterclayton and @deads2k, lgtm'ing

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 1, 2018
@bparees bparees added the lgtm Indicates that a PR is ready to be merged. label Mar 1, 2018
@deads2k
Copy link
Contributor

deads2k commented Mar 1, 2018

Makes me sad, but I doubt we fix it now.

lgetm

@deads2k
Copy link
Contributor

deads2k commented Mar 1, 2018

/cherry-pick release-3.9

@bparees
Copy link
Contributor Author

bparees commented Mar 1, 2018

@deads2k I think it's /cherrypick and anyway I don't deem this critical enough to backport to 3.9 at this point (just in case this new error behavior causes unexpected problems, i'd rather let it soak for a release).

@bparees
Copy link
Contributor Author

bparees commented Mar 2, 2018

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 2, 2018
@bparees
Copy link
Contributor Author

bparees commented Mar 6, 2018

/retest

@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue (batch tested with PRs 18587, 18296, 18667, 18665, 18532).

@openshift-merge-robot openshift-merge-robot merged commit c1befdd into openshift:master Mar 7, 2018
@bparees bparees deleted the ist_defaulting branch March 23, 2018 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot update ImageStreamTags created via Push
4 participants