Handling multiple controller-side validations #167
Labels
kind/design
Categorizes issue or PR as related to design.
olm-v1/m3
priority/important-soon
Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
#142 introduces a validation step in the reconciler to ensure that any bad semvers that slip through the regex validation on the
.spec.version
field are still caught before before the resolver is executed. Without this, a resolution error would be thrown saying the regex cannot be parsed. So, it could be that this isn't necessary (although there is some argument to be made about ensuring the input is clean before it reaches the resolver).The current validation code bails at the first validation failure, stops reconciliation (and doesn't re-enqueue the resource), and adds an
InvalidSpec
condition to the status. When/if we add additional field validators, we'll need to figure out how we want to present this to the user (and whether we want to run the whole validation suite first and collect all the errors, or still bail at the first one). This leads to a discussion of whether we ought to add multiple conditions of the same type (which doesn't seem like best practice), or put everything into one single condition.The text was updated successfully, but these errors were encountered: