kubernetes-client
kubernetes-client copied to clipboard
fabric8io
Expose method that computes the default plural form for a given kind
Is your enhancement related to a problem? Please describe
While there already is Pluralize.toPlural, this actually isn't enough since the kind should also be converted to lower case. It would be nice not to have to bother with knowing that detail.
Describe the solution you'd like
A getDefaultPluralFor(String kind) method on HasMetadata
Describe alternatives you've considered
No response
Additional context
No response
In general, I'd try to move away from Pluralize and rely on the real API plural which differs from the output of Pluralize.toPlural on many occasions.
In general, I'd try to move away from Pluralize and rely on the real API plural which differs from the output of Pluralize.toPlural on many occasions.
I agree but there are cases where you don't get a choice and you'd still want to get the default plural version that is computed by Fabric8, without having to know how it's done. That's why it's called default, btw, not simply plural because it might indeed differ from the actual plural form.
I agree but there are cases where you don't get a choice and you'd still want to get the default plural version that is computed by Fabric8, without having to know how it's done. That's why it's called default, btw, not simply plural because it might indeed differ from the actual plural form.
What we want is precisely to get which cases are these so that we can avoid them altogether. For v7, it would be nice if we could get rid of all of this.
Do you have any examples of which cases might these be?
I agree but there are cases where you don't get a choice and you'd still want to get the default plural version that is computed by Fabric8, without having to know how it's done. That's why it's called default, btw, not simply plural because it might indeed differ from the actual plural form.
Do you have any examples of which cases might these be?
When you're dealing with GenericKubernetesResource and need to get the plural form associated with the GVK to deal with RBACs for example. Ideally, you'd get the plural from the resource class but you might not have the resource class, only the GVK.
Ideally, you'd get the plural from the resource class but you might not have the resource class, only the GVK.
Right now we should be doing that by querying the cluster for the exposed resources just like kubectl does.
Ideally, you'd get the plural from the resource class but you might not have the resource class, only the GVK.
Right now we should be doing that by querying the cluster for the exposed resources just like kubectl does.
I agree that would be the appropriate solution but it's just not possible when you perform that processing at build time and/or you might not be connected to the target cluster.
but it's just not possible when you perform that processing at build time and/or you might not be connected to the target cluster.
Why would you need the plural at build time or when not having direct access to the cluster?
From an operator generation context you should have that already available in the CRD. From any other context, I can't think of why would you need the plural.
but it's just not possible when you perform that processing at build time and/or you might not be connected to the target cluster.
Why would you need the plural at build time or when not having direct access to the cluster?
To generate RBACs which happens at build time. More specifically, when the user is using GenericKubernetesResource for secondary resources, the processor might only get the GVK for the resource, in that case, the plural needs to be inferred from the kind only.
To generate RBACs which happens at build time. More specifically, when the user is using
GenericKubernetesResourcefor secondary resources, the processor might only get the GVK for the resource, in that case, the plural needs to be inferred from the kind only.
Do you have an example or test in the JOSDK repo(s). For me it's still hard to see how the user might have (and provide) the info for the external resources and not be able to manage the plural (how is this dealt with in the regular OSDK? and so on)
To generate RBACs which happens at build time. More specifically, when the user is using
GenericKubernetesResourcefor secondary resources, the processor might only get the GVK for the resource, in that case, the plural needs to be inferred from the kind only.Do you have an example or test in the JOSDK repo(s). For me it's still hard to see how the user might have (and provide) the info for the external resources and not be able to manage the plural (how is this dealt with in the regular OSDK? and so on)
For some more context, see the discussions at https://github.com/operator-framework/java-operator-sdk/pull/2515. For QOSDK, more specifically, see https://github.com/quarkiverse/quarkus-operator-sdk/pull/937/files#diff-b780cb662fc5c0a824655ac29ced7dca9efd35a33f771cd3f3a84a46f21b7cebR134-R147. When QOSDK processes the dependent resources (secondary resources), it's at a point where the user might not have provided the plural form (if they even knew about it) and since happens at build time, checking the API server would be meaningless.
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] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Wonder if this is good approach, if plural cannot be computed in all cases, should we rather force the user to provide it?
That's missing the point. Are model classes providing a plural form by default? No. So either we need this method or expose internal client behavior (which is currently the case) or, at the very least, all model classes should provide a plural form. What the associated PR does is simply to expose the way the client computes the default plural based on the kind instead of forcing people who want to be able to do that to replicate the client's implementation. And, actually, having model classes providing plural form wouldn't even be enough because the use case for this method is when dealing with generic resources where the only thing that's known about the resource is its GVK.
What the associated PR does is simply to expose the way the client computes the default plural based on the kind instead of forcing people who want to be able to do that to replicate the client's implementation.
yes, that is fair, if the goal here is to use this method when on a class there is no explicit plural form set.
And, actually, having model classes providing plural form wouldn't even be enough because the use case for this method is when dealing with generic resources where the only thing that's known about the resource is its GVK.
But this is more problematic, if you know only the GVK, that is simply not enough information to reliably calculate plural form (what is more of an issue with Kubernetes API), so should be the user rather forced to provide it always, as in CRD?
And, actually, having model classes providing plural form wouldn't even be enough because the use case for this method is when dealing with generic resources where the only thing that's known about the resource is its GVK.
But this is more problematic, if you know only the GVK, that is simply not enough information to reliably calculate plural form (what is more of an issue with Kubernetes API), so should be the user rather forced to provide it always, as in CRD?
The goal here is to make it possible to use the same logic as the client to determine the plural when it's not provided or otherwise unavailable, as a best effort kind of thing. I agree that the proper solution is for users to provide the plural form. However, that is just not always possible so this is about being able to use the same logic as the client in that case, without having to re-implement it, not about replacing providing the plural form when possible.
use the same logic as the client to determine the plural when it's not provided or otherwise unavailable, as a best effort kind of thing
I'm repeating this just in case someone misses a previous message in the thread where this was explained (don't want anyone to get confused about this and jump into wrong conclusions)
This is only the case for offline usage. The client always queries the API server (just like kubectl) for the group-version information to be able to retrieve the real plural.
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!
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!