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
Add bundle contents validation #146
Add bundle contents validation #146
Conversation
One thing I've noticed is the api validation library throws a fatal error if the CSV |
6decc3e
to
a709e08
Compare
6d03ad6
to
701dc76
Compare
I think we need to add |
After meeting with the sdk team we want to decouple the image validation and contents validation so that the SDK can import the operator-framework/API directly.
|
f2adc0b
to
cbbe884
Compare
pkg/lib/bundle/validate.go
Outdated
serviceKind: "", | ||
serviceAccountKind: "", | ||
roleKind: "", | ||
roleBindingKind: "", |
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 will also need to include the prometheus types, see: operator-framework/operator-lifecycle-manager#1227
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.
can we export these somehow rather than hardcoding them?
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.
even if that is in the API package and not in the registry? the more things like this that we start adding everywhere the harder it is going to be to change them.
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.
At the moment, there is nothing from OLM or registry to export. For OLM, we use a switch statement to handle all supported types. What OLM supports is a selected set of kube objects so there is no standard or logic for how we pick and choose.
I can create some struct with supported types and a function that validates if the type is supported. However, it is still some sort of "hardcoded".
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.
sure yeah, I undestand that. i mostly just mean now we have to keep track of this in two places and when the list updates remember to update them in both. what happens when the API project wants its own version of this validation for static analysis outside the scope of pulling down the image? Then the list is in 3 places.
not sure if we can solve that here right now, but i think this is a problem that we are facing sooner rather than later for a lot of things that are going to go across all of these projects. what is our import relationship between all of these repositories? or are we trying to explicitly avoid that completely by reimplementing the apis everywhere?
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 agree. There is a need to consolidate some agreements between OLM and registry. I would expect this change to begin with OLM. OLM needs to define a set of kube objects that it is supporting in a way that registry can import and then registry will enforce it during the bundle packaging/building.
numErrors int | ||
errString string | ||
}{ | ||
{ |
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.
a test case for "no csv"? It might change in the future, but for now that's a requirement.
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 understand this case but not sure if it is helpful in this specific situation. If there is no CSV, it is considered PlainType
which we don't validate the contents. So if it is not RegistryV1
format, the ValidateBundleContent
func will just return nil
.
72a7841
to
8f88ed8
Compare
51024cf
to
649aa9f
Compare
1. Add bundle content validation 2. Add the bundle validation documentation 3. Add needed vendor code for validation Signed-off-by: Vu Dinh <vdinh@redhat.com>
…tion 1. Seperate bundle format and content validation into 2 seperate functions 2. Remove operator-sdk reference from registry docs. Using `opm` reference instead. 3. Add bundle object validation to improve content validation Signed-off-by: Vu Dinh <vdinh@redhat.com>
649aa9f
to
8e47858
Compare
/retest |
8e47858
to
dc57d6e
Compare
dc57d6e
to
463dbaa
Compare
/lgtm |
@exdx: you cannot LGTM your own PR. In 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. |
@kevinrizza @ecordell Would like to have the final approval from you :). Thanks |
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.
Two suggestions.
/lgtm |
1. Improve errors handling 2. Flattering some nested conditional loops 3. Refactoring supported types 4. Handle plain type validation Signed-off-by: Vu Dinh <vdinh@redhat.com>
463dbaa
to
0d31556
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dinhxuanvu, exdx, kevinrizza The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
1 similar comment
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dinhxuanvu, exdx, kevinrizza The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description of the change:
Add validation of bundle contents as part of the registry epic. Makes use of the https://github.com/operator-framework/api library for core validation logic. Meant to run along with the bundle image validation. Currently only CSV and CRD manifests are fully validated, other types are simply vetted as valid kube objects.
Signed-off-by: Vu Dinh vdinh@redhat.com
Motivation for the change:
Reviewer Checklist
/docs