CRD singular is same as plural
cben opened this issue · 1 comments
Your custom resource definition has plural name in both plural
and singular
fields:
$ curl -s 'https://raw.githubusercontent.com/awslabs/aws-service-operator/master/configs/aws-service-operator.yaml' | egrep 'singular|plural'
plural: cloudformationtemplates
singular: cloudformationtemplates
plural: dynamodbs
singular: dynamodbs
plural: ecrrepositories
singular: ecrrepositories
plural: elasticaches
singular: elasticaches
plural: s3buckets
singular: s3buckets
plural: snssubscriptions
singular: snssubscriptions
plural: snstopics
singular: snstopics
plural: sqsqueues
singular: sqsqueues
Is this deliberate?
Normally, it should be singular, typically same as kind
only lowercase (in fact that's the default, I think you may omit it).
This seems to be caused by this line:
https://github.com/awslabs/aws-service-operator/blob/8e9a01407f5ae3527b88df2974f73f69e2c17e38/code-generation/pkg/codegen/assets/aws-service-operator.yaml.templ#L28
docs:
https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
"singular name to be used as an alias on the CLI and for display"
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#customresourcedefinitionnames-v1beta1-apiextensions
"Singular is the singular name of the resource. It must be all lowercase Defaults to lowercased kind"
This goes into APIResourceList singularName
field returned in API discovery:
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#apiresource-v1-meta
"singularName is the singular name of the resource. This allows clients to handle plural and singular opaquely. The singularName is more correct for reporting status on a single item and both singular and plural are allowed from the kubectl CLI interface."
This might possibly affect some client libraries. For example, ruby kubeclient gem dynamically generates method names, e.g. get_elasti_cache()
to get one vs get_elasti_caches()
to get many; currently it relies on kind
rather than singularName
but could change in future.
It wasn't on purpose and is a bug. Fix should be coming soon. Thanks!