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

Add bundle contents validation #146

Conversation

exdx
Copy link
Member

@exdx exdx commented Jan 6, 2020

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

  • Implementation matches the proposed design, or proposal is updated to match implementation
  • Sufficient unit test coverage
  • Sufficient end-to-end test coverage
  • Docs updated or added to /docs
  • Commit messages sensible and descriptive

@exdx exdx requested a review from dinhxuanvu January 6, 2020 22:42
@openshift-ci-robot openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jan 6, 2020
@exdx exdx requested review from njhale, ecordell and kevinrizza and removed request for ecordell and jpeeler January 6, 2020 22:42
@exdx
Copy link
Member Author

exdx commented Jan 6, 2020

One thing I've noticed is the api validation library throws a fatal error if the CSV installMode is not explicitly set. I think this is the desired behavior, but all our example manifests including the CSVs in this repo do not have an install mode set. The previous PR on bundle image validation included a valid prometheus CSV that was considered invalid by the api library.

@exdx exdx changed the title feat: validate bundle contents [WIP]feat: validate bundle contents Jan 7, 2020
@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 7, 2020
@exdx exdx force-pushed the feat/validate-bundle-files branch from 6decc3e to a709e08 Compare January 7, 2020 16:46
@dinhxuanvu dinhxuanvu force-pushed the feat/validate-bundle-files branch 4 times, most recently from 6d03ad6 to 701dc76 Compare January 13, 2020 11:28
@dinhxuanvu dinhxuanvu changed the title [WIP]feat: validate bundle contents Add bundle contents validation Jan 13, 2020
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 13, 2020
@exdx
Copy link
Member Author

exdx commented Jan 13, 2020

I think we need to add installMode to the example bundles in this repo (and probably elsewhere) to ensure that our validation passes for our own examples per @ecordell

@exdx
Copy link
Member Author

exdx commented Jan 13, 2020

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.
We should

  • Make a validate bundle command that does not validate image contents (for SDK)
  • Make a validate bundle command that validates image and image contents (for opm alpha)
    cc @kevinrizza

serviceKind: "",
serviceAccountKind: "",
roleKind: "",
roleBindingKind: "",
Copy link
Member

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

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member

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".

Copy link
Member

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?

Copy link
Member

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
}{
{
Copy link
Member

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.

Copy link
Member

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.

pkg/lib/bundle/validate_test.go Show resolved Hide resolved
pkg/lib/bundle/validate.go Outdated Show resolved Hide resolved
pkg/lib/bundle/validate.go Outdated Show resolved Hide resolved
pkg/lib/bundle/validate.go Outdated Show resolved Hide resolved
pkg/lib/bundle/validate.go Outdated Show resolved Hide resolved
@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 16, 2020
@dinhxuanvu dinhxuanvu force-pushed the feat/validate-bundle-files branch 3 times, most recently from 51024cf to 649aa9f Compare January 16, 2020 16:26
exdx and others added 2 commits January 16, 2020 13:30
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>
@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jan 16, 2020
@dinhxuanvu
Copy link
Member

/retest

@exdx
Copy link
Member Author

exdx commented Jan 21, 2020

/lgtm

@openshift-ci-robot
Copy link

@exdx: you cannot LGTM your own PR.

In response to this:

/lgtm

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.

@dinhxuanvu
Copy link
Member

@kevinrizza @ecordell Would like to have the final approval from you :). Thanks

Copy link
Member

@estroz estroz left a comment

Choose a reason for hiding this comment

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

Two suggestions.

pkg/lib/bundle/validate.go Show resolved Hide resolved
pkg/lib/bundle/validate.go Show resolved Hide resolved
@kevinrizza
Copy link
Member

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 21, 2020
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>
@openshift-ci-robot openshift-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. and removed lgtm Indicates that a PR is ready to be merged. labels Jan 21, 2020
@kevinrizza
Copy link
Member

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 21, 2020
@openshift-ci-robot
Copy link

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

1 similar comment
@openshift-ci-robot
Copy link

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

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/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants