Joel Speed

> In any case, I think Kueue could validate the list more precisely as it knows all the registered integrations. I agree. I still think it would be useful to...

Specifically here I'm talking about someone building an operator to run Kueue. Operators are a common pattern across the Kube ecosystem, and often they build APIs that allow configuration of...

I would suggest avoiding the operator requiring Kueue as a library apart from for particular API types (which should have minimal imports), as importing large parts of the codebase can...

I agree that 2 is the approach for a third party controller. I think the important part is that Kueue should enforce the restriction on newly registered integrations, to ensure...

@jhadvig Did you plan to continue with this PR?

> In some cases we might re-use structs for CRDs and some other configuration Can you provide a more detailed explanation of a use case for this? Generally, from an...

Where you are re-using the structs, you mention it's not possible to avoid? Can you provide an example? Where I have seen structs re-used before, one common technique is for...

If the field is in the spec, but cannot be set, what issue does that cause? Is it more from and `kubectl describe` or generated API docs perspective we are...

To make something like this usable, I think we would need to have a way to path the skip behaviour, eg, `+skip:field="self.foo"`. That way it could be used where the...

We may want to look into the [`k8s:subfield`](https://github.com/kubernetes-sigs/controller-tools/issues/1062#issuecomment-2764559115) style that is being introduced into core API validation