Kubernetes and Kubebuilder use different mechanisms to generate plurals

[mrueg]

What broke? What's expected?

Kubernetes uses a custom mechanism to guess and generate plurals for CRDs in https://github.com/kubernetes/apimachinery/blob/master/pkg/api/meta/restmapper.go#L126

Kubebuilder uses https://github.com/gobuffalo/flect which has its own custom set of rules.

kubebuilder/pkg/model/resource/utils.go

Line 72 in 6c11f05

return flect.Pluralize(strings.ToLower(singular))

Although one could argue that the method kubernetes uses is broken and not ideal, it would be great if kubebuilder could apply the same default mechanism to generate plurals so it is easier for kubernetes clients to resolve a resourceplural from a GroupVersionKind mapping.

Reproducing this issue

No response

KubeBuilder (CLI) Version

3.10.0

PROJECT version

No response

Plugin versions

No response

Other versions

No response

Extra Labels

No response

[camilamacedo86]

It has a proposed solution in : #3408
It seems very reasonable ask.

So, I am adding triage accepted.

[lauchokyip]

There are still some discussions happening on this thread kubernetes/kube-state-metrics#2065, should we wait until the consensus is made ?

[rexagod]

Boiling down that thread, the overall ask is to have a de-facto way of pluralizing that helps keep the resource names consistent throughout the ecosystem. I believe using the same logic as apimachinery should allow us to achieve that.

[lauchokyip]

/assign

[Kavinjsir]

Hey @mrueg @rexagod , would you provide some cases/code snippets that come with such an attempt to make the plural consistent? I'm trying to understand how the consistent plural system can help kubernetes clients to resolve a resourceplural from a GroupVersionKind mapping.

[rexagod]

We've had to extract and match plurals to avoid instances where there may be discrepancies between the expected and actual plurals.

[rexagod]

Enforcing a common "de-facto" standard through kubebuilder will solve such cases to a great extent.

[ashutosh887]

Should I take this up? @Kavinjsir @varshaprasad96 @camilamacedo86

[Sajiyah-Salat]

Hello @camilamacedo86 It looks like code issue. Should I work on this?
I have gone through the pr. understood somewhat maybe. I would give it a try if possibe.
If there is anything else I should know or refer to let me know.

[joelanford]

I'm -1 on this change. From an objective grammatical perspective, Kubebuilder's implementation is clearly better than apimachinery's based on the test case changes in the PR. If I'm a kubebuilder user and I see Kubebuilder generate an incorrect plural, I would expect to either notice and fix it myself OR have a reviewer notice it and ask me to fix it, thus adding friction that just gets us back to where things are now.

The GoDoc for the apimachinery function says:

// UnsafeGuessKindToResource converts Kind to a resource name.
// Broken. This method only "sort of" works when used outside of this package. It assumes that Kinds and Resources match
// and they aren't guaranteed to do so.

So "Unsafe" is in the name of the function, and "Broken" is in the GoDoc. It also admits that the function only sort of works when used outside that package. Kubebuilder is outside that package. Why would we want to use it?

Although one could argue that the method kubernetes uses is broken and not ideal, it would be great if kubebuilder could apply the same default mechanism to generate plurals so it is easier for kubernetes clients to resolve a resourceplural from a GroupVersionKind mapping.

But that function is unsafe and broken. Kubebuilder has been in the wild for years generating different plurals. IMO no client should ever expect to correctly resolve a resourceplural from a GVK unless they are using a REST mapper.

[camilamacedo86]

+1000 for @joelanford comments
I think we can convey in defer this one and the requested change could either be proposed to apimachinery.
Why not change there and to do as Kubebuiler does?
It take a while for we end up the plural mechanism which seems more accurate and better then the one used in apimachinery.

On top of that as I raised concerns before it will be a significant breaking change for the users.
So, I am closing this one as reject but if you see that it should be re-opened please feel free to do so.