/area topology

What would be the valid range for those fields?

We don't have these defined right now in the machine webhook (and I don't know if there's any need to), but defining a min/max is an optional part of this.

I think the main part is to ensure that we do enough validation to catch errors like #7047 on object creation, instead of during the reconcile.

Yup. The problem is that metav1.Duration just has type "string" as OpenAPI schema, right?

If it would also use format duration OpenAPI would probably handle it for us? (via: // +kubebuilder:validation:Format)

https://github.com/kubernetes/apiextensions-apiserver/blob/master/pkg/apiserver/validation/formats.go#L49

But given the recent trend we would instead of the marker implement it in the webhook. (the format godoc sounds like we should use time.ParseDuration)

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

/triage accepted
/remove-kind feature
/kind bug

/priority important-soon

This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged.
Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Deprioritize it with /priority important-longterm or /priority backlog
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

/triage accepted

/assign

What happens to the existing users who have persisted bad values when we update the validation here? Has it been considered to use ratcheting validation at all?

I think it was not considered

Ratcheting validation exists directly within the API server from Kube 1.30, but since we need to support older versions, ratcheting can either be implemented in a webhook, or, within a couple of well crafted CEL transition rules (though these aren't perfect as they don't cover the create case).

Without ratcheting, this does have the potential to break users on upgrade, they wouldn't be able to write anything to the object until the values of these broken fields were fixed.

Ratcheting validation exists directly within the API server from Kube 1.30

If it's enabled per default it could be okay to just wait until 1.30 is the min supported version (Cluster API v1.10, basically we could then merge in December)