Support `listKind` property of CRDs

[andreaTP]

Is your enhancement related to a problem? Please describe

In a CRD it should be possible to define a field: spec.names.listKind with a String type. This value should be used for list type operations when accessing the API.

Describe the solution you'd like

It should be possible to decorate a CRD with the following annotation:

@Group("samples.javaoperatorsdk.io")
@Version("v1alpha1")
@ShortNames("jr")
@ListKind("jokesList")
public class JokeRequest extends CustomResource<JokeRequestSpec, JokeRequestStatus> implements Namespaced {}

Describe alternatives you've considered

No response

Additional context

This issue has been originally reported in #5325 .

I'm unsure if/how this is going to impact the underlying REST API calls, maybe @shawkins already has an idea about it.

[shawkins]

I'm unsure if/how this is going to impact the underlying REST API calls, maybe @shawkins already has an idea about it.

listKind already defaults to kindList. I'm not sure when someone would what to override that. I would guess that the default list serving via the server would be the same either way, just the kind would be different.

There could be some super advanced stuff where you could add custom stuff to the list, but that seems like it would require defining the list type in the crd as well.

For our typed api if you make a client.resources(type) call it will expect that the list type is classnameList - if that can't be found it will just deserialize as DefaultKubernetesResourceList. If you override the listKind, you'd may instead need to use client.resources(type, listType) so that it knows what the custom list type is. Again this would only make a difference if there were something different about what was in the custom list type. If this is a common scenario, then we'll need to add the list kind / type to the ResourceDefinitionContext and potentially from the metadata we lookup.

[andreaTP]

I don't think this is used often, but it might impact some edge cases: https://github.com/kubernetes/kubernetes/issues/87133

[shawkins]

I don't think this is used often, but it might impact some edge cases: https://github.com/kubernetes/kubernetes/issues/87133

After looking things over more I think it's just for resolving kind conflicts - for example if you have a CR called FooList and one called Foo, you need to override the listKind for Foo.

In practical terms then there's little signifigance to the kubernetes client - but without tracking more metadata it will require using client.resources(Foo.class, AltListKindFooList.class)

[andreaTP]

@metacosm can we assign this to you?

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[brycefisher]

I'm consuming the helm chart from the flink-kubernetes-operator project, which in turn appears to be leveraging fabric8/kubernetes-client to generate the helm-chart. In that helm chart, there's no listKind in the CRD yaml. Is there any testing inside kubernetes-client that listKind is automatically set?

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!