-
Notifications
You must be signed in to change notification settings - Fork 259
OCPBUGS-13547: make reading rendered manifests easier #1516
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
OCPBUGS-13547: make reading rendered manifests easier #1516
Conversation
JoelSpeed
left a comment
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.
The changes here will 100% block users from using CustomNoUpgrade manifests at install time, I think that's in keeping with other changes we are making, but we should make sure that we allow this in the future, I know various CI jobs still use the custom manifests, but perhaps not via install-time.
Will take a look at the release repo to verify
| return ret | ||
| } | ||
|
|
||
| func (renderedManifests RenderedManifests) GetManifest(gvk schema.GroupVersionKind, namespace, name string) *RenderedManifest { |
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.
Why does this return a pointer when previously we were returning a fresh slice of the objects? Does it need to be a pointer?
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.
Why does this return a pointer when previously we were returning a fresh slice of the objects? Does it need to be a pointer?
nil, versus error on missing. I'll yield to your preference.
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.
I think I would go for an error and return the errors we find along the way as well, if an operator chooses to ignore the error, thats on them to decide how to handle it, but if they require the manifest, including as much error detail in the return seems useful IMO
3505704 to
f78b491
Compare
JoelSpeed
left a comment
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.
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, JoelSpeed 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 |
|
@deads2k: 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/test-infra repository. I understand the commands that are listed here. |
|
proof worked /hold cancel |
|
@deads2k: Jira Issue OCPBUGS-13547: Some pull requests linked via external trackers have merged: The following pull requests linked via external trackers have not merged:
These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with Jira Issue OCPBUGS-13547 has not been moved to the MODIFIED state. 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/test-infra repository. |
/hold
This would require that manifests be consistent with each other. They should be already given random retries, but this is a choice.