Add support for CRD field selectors

[scholzj]

Kubernetes 1.32 added stable support for custom resource field selectors. This should allow filtering of custom resources based on some field from the custom resource itself.

This might be useful in several situations:

• To allow users easily filter the resources ... users might have many topics or users, would some fields from their spec make sense for filtering?
• To replace the strimzi.io/cluster labels with a field in the resource spec and then use it by the Kubernetes client to inform only on some resources

If we decide that this is useful, we will likely need:

• Figure out which field should support this
• Add the support to the CRD generator through an annotation on the API classes

Note: This moved to stable only in 1.32 and it is likely not possible to use it today because of backward compatibility. But should be revisited in the future)

[ppatierno]

To replace the strimzi.io/cluster labels with a field in the resource spec and then use it by the Kubernetes client to inform only on some resources

I was wondering what's the advantage of having a field in the spec (which is then part of the API) when you can already filtering on labels?

[scholzj]

I was wondering what's the advantage of having a field in the spec (which is then part of the API) when you can already filtering on labels?

For example better validation? Possible (future) integration across namespaces?

[ppatierno]

better validation?

Can't you validate within the operator against a label instead of accessing a spec field? I don't see much difference from code perspective. If you get some validation from the Kubernetes API (before reaching the operator code) then it's different.

Possible (future) integration across namespaces?

Wdym by this?

[scholzj]

better validation?

Can't you validate within the operator against a label instead of accessing a spec field? I don't see much difference from code perspective. If you get some validation from the Kubernetes API (before reaching the operator code) then it's different.

We validate all kinds of .spec properties as part of the CRD schema before it is even stored in Kubernetes.

Possible (future) integration across namespaces?

Wdym by this?

Pointing not just to a resource, but possibly to a resource in another namespace.

[ppatierno]

We validate all kinds of .spec properties as part of the CRD schema before it is even stored in Kubernetes.

But in this case it would be just a String representing the cluster name. Which kind of validation are you envisaging?

[scholzj]

We validate all kinds of .spec properties as part of the CRD schema before it is even stored in Kubernetes.

But in this case it would be just a String representing the cluster name. Which kind of validation are you envisaging?

For example that it is present.

[katheris]

Triaged on 20.2.2025: This feature seems like a good idea, but we would need to wait until all versions of Kubernetes we support work with this feature, incase for example with older versions the CRD would fail. We should keep this open and work on it in future.