When warning about a dropped field, the StatusCause needs a type.

Not sure whether a new type is needed. The closest existing one is "FieldValueNotSupported", which kind of makes sense because the non-nil field in the parent struct is also a value...

Still debating with myself what the best return values are here...

The error only gets added for the sake of completeness as I am touching this method and all implementations. It seems useful that an implementer should also be able to say "stop right now, something is completely wrong" here. But for warnings about dropped fields its not needed.

I'm currently using warnings []string for consistency with WarningsOnCreate. That's fine when just passing those warnings through and has the advantage that warnings are not limited to dropped fields.

But when converting the warnings to an error, the caller has to parse the warning and provide a common error text, so in the end those have to be warnings about dropped fields and they have to have the expected format.

I'm therefore leaning towards a less flexible return value. field.ErrorList is too flexible because Error has additional fields (Type, BadValue) that we don't need.

[]struct{Field string, Message string} ?

Alternatively, we can keep the prototype as it is and require that implementations themselves turn warnings into an error for fieldValidation == "Strict", then return that error instead of warnings. A helper function could be provided which does that.

A couple thoughts:

1. I'd need to think more about what it would mean to add a fatal error return to this code path
2. If possible, I'd want to handle what we do with dropped fieldPaths centrally and minimize the surface area / reliance on dozens of individual strategy methods constructing consistent messages and distinguishing between warn and error correctly

I think the minimal surface area required here is:

1. In parameters, tell PrepareForCreate / PrepareForUpdate if the caller needs to know about dropped field paths (since it adds some complexity / cost to accumulate those ... if fieldValidation is "Ignore", there's no point in doing that work)
2. In the return value, let PrepareForCreate / PrepareForUpdate return any dropped field paths, possibly with an associated reason string for each about why they were dropped

If we're changing the strategy signature, I'd probably plan for the future and add an input type and a return type we can augment in the future if needed

possibly something like:

type PrepareForCreateOptions struct {
  ReturnDroppedFieldPaths bool
}
type PrepareForCreateResult struct {
  DroppedFieldPaths []string // or map[string]string to give associated reasons?
}
PrepareForCreate(ctx context.Context, obj runtime.Object, opts PrepareForCreateOptions) PrepareForCreateResult

type PrepareForUpdateOptions struct {
  ReturnDroppedFieldPaths bool
}
type PrepareForUpdateResult struct {
  DroppedFieldPaths []string // or map[string]string to give associated reasons?
}
PrepareForUpdate(ctx context.Context, obj, old runtime.Object, opts PrepareForUpdateOptions) PrepareForUpdateResult

Then, in the one place we call these methods, we decide if we care about tracking dropped field paths based on whether we need to warn or error, and we handle warning or erroring based on the result

If possible, I'd want to handle what we do with dropped fieldPaths centrally and minimize the surface area / reliance on dozens of individual strategy methods constructing consistent messages and distinguishing between warn and error correctly.

Fully agreed. Whatever we do, it would be a lot of manual work.

In addition, like validation itself it also is conceptually at the wrong place: the field paths are for the internal API version. If the external APIs do not all use exactly the same paths, then users get confusing errors or warnings for those API versions with different paths. DRA will have this situation because we are restructuring a bit in v1beta2.

This leads me to: can we do this as part of declarative validation?

We already have the +featureGate annotation. Generating code which does the usual "if any feature-gated field is set or feature gate enabled, return, otherwise drop feature-gated fields" logic should be doable.

/cc @alexzielenski @jpbetz @yongruilin

This leads me to: can we do this as part of declarative validation?

Only if we can guarantee we never error / warn for this on an update of an existing object that already contains data in that field

Generating code which does the usual "if any feature-gated field is set or feature gate enabled, return, otherwise drop feature-gated fields" logic should be doable.

Are we able to perfectly automatically detect / correlate use of the gated field in the old object?

Only if we can guarantee we never error / warn for this on an update of an existing object that already contains data in that field

That's what I meant with "if any feature-gated field is set" - just accidentally dropped the "in the existing object".

Are we able to perfectly automatically detect / correlate use of the gated field in the old object?

That's a question to the people implementing declarative validation. We would need access to the stored object in the same version that the incoming update has. Then whatever is set there should match the +featureGate annotations and thus the code generated for that version.

This conversion into an error needs to go into some helper function, either one that is shared by create and update or exported such that implementations can use it.

As a proof-of-concept I've converted this "drop disabled fields". There's a corresponding E2E test in test/e2e/dra.go.

If we go ahead with this, do I need to update all "drop disabled fields" implementations and write tests for that in this PR? It would be desirable for the sake of consistency, but also a lot of busy work and lead to a very large PR.

The alternative is to add the ability to do this in one PR, then convert individual API types one-by-one. That work can be spread across different contributors.

I'm leaning towards the latter approach. They key argument is that clients cannot rely on getting an error for a while because they probably need to support also older Kubernetes release where this new functionality wasn't available yet. For DRA, we need such a "plan B" for DRA drivers running on Kubernetes 1.32.