Skip to content

Handling multiple controller-side validations #167

@perdasilva

Description

@perdasilva

#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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/designCategorizes issue or PR as related to design.olm-v1/m3priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions