Add "valid" condition to all resources #55
Conversation
All resources will be evaluated by their controllers after they are created to determine if they are valid or not. This PR adds a "Valid" condition to the status of all resoruces which can be used by the controller to inform the user of this (otherwise I think we'd have to implement this kind of validation via admission controllers? maybe that's better?) This would be used by the logic that will be implemented for validation in #33 #32 #31 #29 #30.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bobcatfish 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 |
knative-prow-robot
added
size/L
|
Particularly interested in hearing whether folks think it would be more appropriate for validation to be implemented in each type's controller, or if it would make more sense to create admission controllers for this. This is to check things like:
|
|
Using |
|
@pivotal-nader-ziada that backs up what @mattmoor said as well:
And I think that would take care of @tejal29 's point as well:
Since the webhook would prevent the resources from being installed. So I'll close this PR then! Note: I was hoping that using webhooks would mean we didn't have to block implementing validation on the kubebuilder decision (#19) but it looks like kubebuilder provides libs for webhooks as well: https://book.kubebuilder.io/beyond_basics/sample_webhook.html |
|
sounds good! yes we can have webhook admission controllers. |
Modify EventListener and TriggerBinding such that TriggerBindings can be reused. This was proposed and discussed in tektoncd#55 . Instead of specifying a particular TriggerTemplate within a TriggerBinding (as was previously proposed), users now specify one-to-one relationships between TriggerBindings and TriggerTemplates within an EventListener. Catalogs of TriggerTemplates can exist and be reused with this change. Although adding Params may be something we want to do for reusability in the future, particularly for the case where filtering/conditions are embeded within the TriggerBinding, it is out of this PR's scope. We may separate the conditional/filtering logic in which case parameters would make more sense there anyway. Co-authored-by: Vincent-DeSousa-Tereso <[email protected]>
All resources will be evaluated by their controllers after they are
created to determine if they are valid or not. This PR adds a "Valid"
condition to the status of all resoruces which can be used by the
controller to inform the user of this (otherwise I think we'd have to
implement this kind of validation via admission controllers? maybe
that's better?)
This would be used by the logic that will be implemented for validation
in #33 #32 #31 #29 #30.