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 validations for customresourcedefinitions and apiservicedefinitions #112

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

darkowlzz
Copy link
Contributor

Adds _csv_crd_validation() and _csv_asd_validation for validating csv.spec.customresourcedefinitions and csv.spec.apiservicedefinitions respectively.
Also validates the descriptors in both CRD and ASD using a common method _csv_descriptors_validation().

@openshift-ci-robot openshift-ci-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Apr 23, 2019
@openshift-ci-robot
Copy link

Hi @darkowlzz. Thanks for your PR.

I'm waiting for a operator-framework or openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

Copy link
Contributor

@SamiSousa SamiSousa left a comment

Choose a reason for hiding this comment

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

Adding these validations will be a great help, but I think we need to agree to what extent we are validating the CSV

name = crd["metadata"]["name"]
crdList.append(name)
except KeyError:
pass
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this log a warning or error informing the user that a CRD is missing the metadata.name field? It's better to be noisy than quiet in this case (unless we previously warn elsewhere)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

pass

if "owned" not in customresourcedefinitions:
self._log_error("spec.customresourcedefinitions.owned"
Copy link
Contributor

Choose a reason for hiding this comment

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

Not all operators that have the customresourcedefinitions field operate on "owned" CRDs. I believe this should be an early exit rather than a logged error

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that having customresourcedefinitions without any subfields should raise an error. But there are other values than "owned" that could exist here (such as required: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/Documentation/design/building-your-csv.md#required-crds)

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that having customresourcedefinitions without any subfields should raise an error.

To contradict myself, what's the benefit of enforcing that subfields exist?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, those are not required fields. We shouldn't invalidate here.
Enforcement is beneficial only if we know that no subfields result in insall failure. I don't think that's the case here.

def _csv_asd_validation(self, apiservicedefinitions):
valid = True

if "owned" not in apiservicedefinitions:
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, and owned and required aren't required fields, so we shouldn't invalidate here.
I'll leave required validation for a separate PR, will validate owned only for now.

@@ -312,6 +413,31 @@ def _csv_spec_install_validation(self, install):

return valid

def _csv_descriptors_validation(self, descriptors, crdName):
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we also check that the x-descriptors (if it exists) field is a list of strings?
Eq: https://github.com/operator-framework/community-operators/blob/master/community-operators/cluster-logging/cluster-logging.v4.1.0.clusterserviceversion.yaml#L275
Not sure if this is a requirement, more like an observation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, thanks for the idea, that would be useful and I would like to add that in a separate PR. This PR is already huge.

@@ -38,7 +38,8 @@ metadata:
name: dynatrace-monitoring.v0.2.0
namespace: "placeholder"
spec:
apiservicedefinitions: {}
apiservicedefinitions:
owned: {}
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we requiring that if the apiservicedefinitions or customresourcedefinitions fields exist that they have owned as a sub field (or the presence of any valid sub field)?
(Also this should be a list not an object)

Copy link
Contributor

Choose a reason for hiding this comment

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

Is our stance that if it exists and is empty that is valid? If so, these both should be valid:

spec:
  apiservicedefinitions: {}

and

spec:
  apiservicedefinitions:
    owned: []

Copy link
Contributor

Choose a reason for hiding this comment

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

I want to clarify that my stance is based on my observations of the existing community-operators CSVs, many of which set spec.apiservicedefinitions to the empty object {}.
We could enforce that the key owned exists, but should we/does it create any benefit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. This was a mistake based on requiring owned. owned is not required, and this change is not needed.

spec.customresourcedefinitions.owned CRDs must have displayName and
description and values must not be empty.

Validate the attributes of csv owned crd descriptors.
@flickerfly
Copy link

/test

Because I'm interested in this work and it has been awhile.

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 9, 2021
@openshift-ci-robot
Copy link

@darkowlzz: PR needs rebase.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. 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.

4 participants