Add validations for customresourcedefinitions and apiservicedefinitions#112
Add validations for customresourcedefinitions and apiservicedefinitions#112darkowlzz wants to merge 3 commits intooperator-framework:masterfrom
Conversation
|
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 Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
SamiSousa
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
operatorcourier/validate.py
Outdated
| pass | ||
|
|
||
| if "owned" not in customresourcedefinitions: | ||
| self._log_error("spec.customresourcedefinitions.owned" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
I agree that having
customresourcedefinitionswithout any subfields should raise an error.
To contradict myself, what's the benefit of enforcing that subfields exist?
There was a problem hiding this comment.
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.
operatorcourier/validate.py
Outdated
| def _csv_asd_validation(self, apiservicedefinitions): | ||
| valid = True | ||
|
|
||
| if "owned" not in apiservicedefinitions: |
There was a problem hiding this comment.
An operator may also have "required" apiservicedefinitions: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/Documentation/design/building-your-csv.md#required-apiservices
There was a problem hiding this comment.
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.
|
|
||
| return valid | ||
|
|
||
| def _csv_descriptors_validation(self, descriptors, crdName): |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| spec: | ||
| apiservicedefinitions: {} | ||
| apiservicedefinitions: | ||
| owned: {} |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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: []
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
7952ae6 to
983e781
Compare
|
/test Because I'm interested in this work and it has been awhile. |
|
@darkowlzz: PR needs rebase. 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. |
Adds
_csv_crd_validation()and_csv_asd_validationfor validatingcsv.spec.customresourcedefinitionsandcsv.spec.apiservicedefinitionsrespectively.Also validates the descriptors in both CRD and ASD using a common method
_csv_descriptors_validation().