-
Notifications
You must be signed in to change notification settings - Fork 53
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
base: master
Are you sure you want to change the base?
Add validations for customresourcedefinitions and apiservicedefinitions #112
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. 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. |
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.
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.
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)
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.
operatorcourier/validate.py
Outdated
pass | ||
|
||
if "owned" not in customresourcedefinitions: | ||
self._log_error("spec.customresourcedefinitions.owned" |
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.
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.
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)
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 that having
customresourcedefinitions
without 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.
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.
operatorcourier/validate.py
Outdated
def _csv_asd_validation(self, apiservicedefinitions): | ||
valid = True | ||
|
||
if "owned" not in apiservicedefinitions: |
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.
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.
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): |
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.
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.
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: {} |
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.
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.
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: []
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 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.
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.
7952ae6
to
983e781
Compare
/test Because I'm interested in this work and it has been awhile. |
@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. |
Adds
_csv_crd_validation()
and_csv_asd_validation
for validatingcsv.spec.customresourcedefinitions
andcsv.spec.apiservicedefinitions
respectively.Also validates the descriptors in both CRD and ASD using a common method
_csv_descriptors_validation()
.