-
Notifications
You must be signed in to change notification settings - Fork 587
MULTIARCH-4556: Introduce ImageStreamImportMode field in the image config #1928
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
MULTIARCH-4556: Introduce ImageStreamImportMode field in the image config #1928
Conversation
|
@Prashanth684: This pull request references MULTIARCH-4556 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Hello @Prashanth684! Some important instructions when contributing to openshift/api: |
e498a31 to
3275b7a
Compare
|
/test e2e-aws-ovn-techpreview |
|
/test e2e-upgrade |
|
|
config/v1/types_image.go
Outdated
| package v1 | ||
|
|
||
| import metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" | ||
| import imagev1 "github.com/openshift/api/image/v1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this import shouldn't happen. It couples our configuration to an image API that may evolve independently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does in a way depend on how the image API evolves though..if there is a change in the image API, I would assume we would want that to reflect in this field. Also, if we don't base this on the image API, then what about the field in the openshiftapiserver imagepolicyconfig? Would it be ok if that depends on the image API ? It is set based on the import mode in the image config status.
5fb1723 to
93e83ff
Compare
93e83ff to
d993f5b
Compare
a83b1bf to
1182481
Compare
When working on openshift#1928, noticed that the paylaod crds were not being generated after running a `make update`. This is because codegen is run after update-scripts. This PR removes update-payload-crds from update-scripts and runs it after codegen.
1182481 to
b921863
Compare
ah..thanks for the catch..there was an indentation error in the ungated file. fixed it. The verify-crd-schema still fails, but think it is expected. |
These are already existing fields in an already existing CRD. is the change simply to add |
This is the api implementation for openshift/enhancements#1605 - Introduces ImageStreamImportMode field in the image config spec and status - the status will be consumed by apiserver to set importMode for all imagestreams - Introduce an `ImageStreamImportMode` tech preview feature gate - Add feature gate test
11edb6c to
fa3fbfe
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JoelSpeed, Prashanth684 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/verify-crd-schema DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/retest-required |
|
/test e2e-upgrade-minor |
1 similar comment
|
/test e2e-upgrade-minor |
|
/override ci/prow/e2e-upgrade-minor The minor upgrade has been broken since branching, I'm working on fixing it. Looking at the changes here the only upgrade potential issue would be the new SSA tags, but they are all atomic which is the default anyway, so there's no actual functional change |
|
@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/e2e-upgrade-minor DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@Prashanth684: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This PR openshift/api#1928 introduced a string field which has no omitempty tag. This result in our mashalling transparently changing. This produces a different configuration Hash. This PR drops the field when empty from the mashalled string to keep backward compatibility. Implementing this at the marshal operation level might result in undesired impact as we might pontetially modify other fields and ordering is not deterministic. The PR also increases test coverage using raw strings to make sure they fail if any input for our Hash generation ever changes transparently
This PR openshift/api#1928 introduced a string field which has no omitempty tag. This result in our mashalling transparently changing. This produces a different configuration Hash. This PR drops the field when empty from the mashalled string to keep backward compatibility. Implementing this at the marshal operation level might result in undesired impact as we might pontetially modify other fields and ordering is not deterministic. The PR also increases test coverage using raw strings to make sure they fail if any input for our Hash generation ever changes transparently
This PR openshift/api#1928 introduced a string field which has no omitempty tag. This result in our mashalling transparently changing. This produces a different configuration Hash. This PR drops the field when empty from the mashalled string to keep backward compatibility. Implementing this at the marshal operation level might result in undesired impact as we might pontetially modify other fields and ordering is not deterministic. The PR also increases test coverage using raw strings to make sure they fail if any input for our Hash generation ever changes transparently
This PR openshift/api#1928 introduced a string field which has no omitempty tag. This result in our mashalling transparently changing. This produces a different configuration Hash. This PR drops the field when empty from the mashalled string to keep backward compatibility. Implementing this at the marshal operation level might result in undesired impact as we might pontetially modify other fields and ordering is not deterministic. The PR also increases test coverage using raw strings to make sure they fail if any input for our Hash generation ever changes transparently
This PR openshift/api#1928 introduced a string field which has no omitempty tag. This result in our mashalling transparently changing. This produces a different configuration Hash. This PR drops the field when empty from the mashalled string to keep backward compatibility. Implementing this at the marshal operation level might result in undesired impact as we might pontetially modify other fields and ordering is not deterministic. The PR also increases test coverage using raw strings to make sure they fail if any input for our Hash generation ever changes transparently
This PR openshift/api#1928 introduced a string field which has no omitempty tag. This result in our mashalling transparently changing. This produces a different configuration Hash. This PR drops the field when empty from the mashalled string to keep backward compatibility. Implementing this at the marshal operation level might result in undesired impact as we might pontetially modify other fields and ordering is not deterministic. The PR also increases test coverage using raw strings to make sure they fail if any input for our Hash generation ever changes transparently (cherry picked from commit 045ba5c)
This PR openshift/api#1928 introduced a string field which has no omitempty tag. This result in our mashalling transparently changing. This produces a different configuration Hash. This PR drops the field when empty from the mashalled string to keep backward compatibility. Implementing this at the marshal operation level might result in undesired impact as we might pontetially modify other fields and ordering is not deterministic. The PR also increases test coverage using raw strings to make sure they fail if any input for our Hash generation ever changes transparently
This is the api implementation for openshift/enhancements#1605
ImageStreamImportModetech preview feature gate