Resource trait to expose resource name

[clux]

Currently, we have to infer the resource name from kind by pluralising it when creating our Api (https://github.com/clux/kube-rs/issues/284)

Is the plural name available when you are generating? I see you are using pluralised names somehow, but haven't figured out where it's from.

if it's available, is it possible to add it to the Resource trait as another associated const? It would help us drop hacky inflector dependencies and avoid potential errors.

[Arnavion]

Is the plural name available when you are generating? I see you are using pluralised names somehow, but haven't figured out where it's from.

For code generated by k8s-openapi-codegen, the URLs come from the openapi spec.

For CRDs created with #[derive(CustomResourceDefinition)], the user has to provide the plural that the URLs are synthesized from.

[clux]

Ah, I see. Looks like it's grabbed from the parts of the spec that looks like:

{
  "/apis/apps/v1/deployments": {
    "get": {
      "consumes": [
        "*/*"
      ],
      "description": "list or watch objects of kind Deployment",
      "operationId": "listAppsV1DeploymentForAllNamespaces",
      "tags": [
        "apps_v1"
      ],
      "x-kubernetes-action": "list",
      "x-kubernetes-group-version-kind": {
        "group": "apps",
        "kind": "Deployment",
        "version": "v1"
      }
    },
    "parameters": []
  }
}

so if i understand it correctly, k8s-openapi is not really aware of the plural names at all.. unless it were to do some magic like slicing the root url of each group-version-kind's to aggregate this extra information... Would that be feasible? Would you even want that?

[Arnavion]

so if i understand it correctly, k8s-openapi is not really aware of the plural names at all..

Exactly.

unless it were to do some magic like slicing the root url of each group-version-kind's to aggregate this extra information... Would that be feasible? Would you even want that?

I don't think so. Plural names for CRDs are completely arbitrary, and for built-ins they're hardcoded into the API server source. The API server doesn't care if plurals correlate to the singular names in any way, and it certainly doesn't derive plural names from singular names by itself. So having k8s-openapi or even a client layer automatically do it doesn't seem like a good idea.

[Arnavion]

Hmm, thinking about this more, your idea might work. The URL is always going to be /$group/$api_version/$plural/..., so it shouldn't be a big deal to slice the $plural out.

Adding it to the Resource trait also has the advantage for #[derive(CustomResourceDefinition)], because currently it requires the user to use the plural separate for registration, whereas with this they could get it from the trait directly.

Let me think about it.