Feature Request: Provide an explicit way to opt out of type-level validations

[lalitc375]

Problem

Currently, when reusing a Go type in a CRD, the validation rules associated with that type are automatically applied. However, there are use cases where users want to reuse a type but apply different validation rules. The current workaround is to create a new type without validations, which becomes a maintenance burden when there are many minor differences.

Proposal

Introduce a marker, such as +k8s:opaque, that can be used on a field to disable the generation of type-level validations for that field. Field-level validation annotations on the field would still be processed and applied.

This would allow users to reuse existing types without inheriting their validation rules, and instead define custom validation for the field as needed.

This approach is similar to the opaque validation of Declarative validation, KEP-5073.

Example

// Original type with validation
// +kubebuilder:validation:MaxLength=10
type MyString string

// CRD that reuses MyString but with different validation
type MyCRD struct {
    // +k8s:opaque
    // +kubebuilder:validation:MaxLength=5
    MyField MyString `json:"myField"`
}

In this example, the generated validation for MyField would only check for a maxLength of 5, and the maxLength=10 from MyString would be ignored.

[lalitc375]

cc: @JoelSpeed @aaron-prindle

[JoelSpeed]

We recently made a change to the way controller tools works to allow overriding at the field level anyway. We need to consider how something like this would interact. The current method is a partial override, where this would be a complete override.

If this is something supported by DV, then we should absolutely support it.

CC @sbueringer @alvaroaleman for awareness

[JoelSpeed]

Speaking further with @lalitc375 we want to make a decisions about whether the override logic we recently added (#1270) but has not been released, should be reverted to make this something that is an explicit choice, rather than still having the ability to locally override

[alvaroaleman]

IMHO if we are unsure, we should remove it. Adding something in the future is easy, removing is near-impossible as it will break ppl

[JoelSpeed]

I'll try and take a look at my PR again and see if there's a way to avoid this without re-introducing the bug