🌱 Add basic validation for time duration

[Dhairya-Arora01]

Basic validation for time duration can be done using kubebuilder markers to match the pattern "^(([1-9][0-9]*(\.[0-9]+)?|0?\.[0-9]+)(ns|us|µs|ms|s|m|h))+$",

What this PR does / why we need it: Basic validation for time duration can be done using kubebuilder markers to match the pattern "^(([1-9][0-9]*(\.[0-9]+)?|0?\.[0-9]+)(ns|us|µs|ms|s|m|h))+$"

Examples of valid matches:

• 1s
• 23ms
• 0.123us
• 456.789µs
• 1m30s
• 2h15m

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #7104

[k8s-ci-robot]

This PR is currently missing an area label, which is used to identify the modified component when generating release notes.

Area labels can be added by org members by writing /area ${COMPONENT} in a comment

Please see the labels list for possible areas.

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-sigs/prow repository.

[k8s-ci-robot]

Hi @Dhairya-Arora01. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign killianmuldoon for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vincepri]

Could we add a simple test for common values?

[Dhairya-Arora01]

Could we add a simple test for common values?

Also now I think, this validation should be everywhere we use time.Duration type. wdyt?
@vincepri how can i test this? like we can't just test it by populating the fields with these strings for the Cluster object.

[JoelSpeed]

Are these validations pre-existing in a webhook? What would happen if a user already has an invalid value?

[JoelSpeed]

If you were to use CEL here, you could create a custom error message which may be more helpful to end users, rather than just printing the regex as will happen when this fails, WDYT?

CEL pattern validation has been around since K8s 1.25 (beta originally) so I think all supported K8s versions CAPI targets should handle this

[sbueringer]

1.28 is the min supported mgmt cluster version in CAPI 1.9.

Just have to make sure that whatever we do in CEL works with 1.28 (the Kubernetes CEL library is still adding new stuff with recent Kubernetes versions)

[Dhairya-Arora01]

how about this validation rule:

// +kubebuilder:validation:XValidation:rule="self.matches('^(([1-9][0-9]*(\\.[0-9]+)?|0?\\.[0-9]+)(ns|us|µs|ms|s|m|h))+$')",message="Invalid duration format. Must be a positive number followed by a unit (ns, us, µs, ms, s, m, h). Examples: 300ms, 2h45m, 1.5h"

this supports the error message too, but the pattern matching marker does not!

[fabriziopandini]

Should we have a discussion before going down the path of introducing a mix of open API and go validations?
Asking because as far as I remember we rely on go validations in a few places in the codebase, and changes like this could make those code path more fragile (disclaimer: I need some more time to reasearch usage of go validations, but I'm not sure when I could get to it)

/hold

[JoelSpeed]

@fabriziopandini we should definitely have this discussion and try and come up with a plan forward, my 0.02 below.

In general, I think in the past, OpenAPI validation hasn't been up to scratch for the majority of our needs in terms of API validation. Modern CRD validation however, is much more powerful, and I think as a community we should start transitioning towards it more and more.

From an end user perspective, what we need to achieve is validation that presents at admission time. That could be implemented either as a webhook, or through openapi. In terms of validating the end user experience, a test suite that executes envtest and applies resources and inspects output errors should allow us to test both webhook validations and openapi at the same time.

Once we have this test suite in place, we could start moving validations from the webhook to the openapi validation to move more and more validation in-tree and reduce the usage of the webhook. This means less for us to maintain, and, when we can eventually use match conditions, we could even get to a point where the webhook is only called explicitly when it is needed. Which would further reduce usage of the webhook, and improve the runtime performance of our APIs, and hopefully improve the ability to scale management clusters.

OpenAPI validation inside the CRD schema can only look at the object we have in question, so anything that relies on validating based on fields from other CRs, requires something more. This can either be a webhook, or validating admission policy which can use params as input from other resources. This would be another way that we could reduce webhook validations by providing a set of VAPs that are installed alongside CRDs, and again, this has the benefit of being in-tree validation.

The other benefit of openapi based validation that I can think of is that it means that the CRD validations are at the point where the fields are defined. It's very easy to review the field context as a whole, you can see the godoc, and all of the validations applied to it in one small piece of code. This should help with comprehension of how the field behaves, and, IMO, helps us to improve the documentation. If I see a CEL rule that's not explained in the godoc, its easy to point out that this should be explained in the docs. If it's in a webhook, I'm less likely to pick up that it's not documented.

There are of course trade offs to consider, primarily for us, I think, is the minimum supported version of Kube. This validation has been and still is evolving. Any API testing we do, must be against our lowest supported version, and therefore, some of the newer features of CRD validation we may not be able to use just yet, meaning this journey, if we choose to embark upon it, might take some time.

[fabriziopandini]

@JoelSpeed I agree with most of your points. I just want to make sure that we making this to happen in an organic way, taking care of testing, of not breaking where we are using defaulting/validation logic outside of the webhooks, etc.
Possibly, we need also a plan defining how much of this work should go in the next API version