apiextensions-apiserver: Plural name for CRD doesn't work with kubectl

My CRD for Elasticsearch

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  labels:
    app: kubedb
  name: elasticsearches.kubedb.com
spec:
  group: kubedb.com
  names:
    kind: Elasticsearch
    listKind: ElasticsearchList
    plural: elasticsearches
    shortNames:
    - es
    singular: elasticsearch
  scope: Namespaced
  version: v1alpha1
status:
  acceptedNames:
    kind: Elasticsearch
    listKind: ElasticsearchList
    plural: elasticsearches
    shortNames:
    - es
    singular: elasticsearch
  conditions:
  - lastTransitionTime: null
    message: no conflicts found
    reason: NoConflicts
    status: "True"
    type: NamesAccepted
  - lastTransitionTime: 2017-08-31T07:10:38Z
    message: the initial names have been accepted
    reason: InitialNamesAccepted
    status: "True"
    type: Established

None of the following commands is working

$ kubectl get elasticsearch
Error from server (NotFound): Unable to list "elasticsearchs": the server could not find the requested resource (get elasticsearchs.kubedb.com)

kubectl get elasticsearches
the server doesn't have a resource type "elasticsearches"

kubectl get es
the server doesn't have a resource type "elasticsearches"

But I got correct SelfLink

/apis/kubedb.com/v1alpha1/elasticsearches

Here, I have used elasticsearches as plural form of elasticsearch.

How can I fix this and use elasticsearches as plural for kind Elasticsearch?

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (9 by maintainers)

Most upvoted comments

@frankgreco The fix is present in 1.7.8: https://github.com/kubernetes/kubernetes/blob/v1.7.8/staging/src/k8s.io/apimachinery/pkg/api/meta/restmapper.go. 😃

However, k8s.io/apiextensions-apiserver is not upto date. The bot required to sync k8s.io/apiextensions-apiserver with kubernetes/kubernetes is currently being fixed now. Should be fixed soon afaik.

nikhita on Oct 8, 2017

@frankgreco Sounds perfect! 😃

nikhita on Oct 4, 2017

Awesome, so if I understand correctly, the steps that would need to be completed before this is working e2e in my cluster would be:

Wait for the kubernetes/kubernetes repo to be synced with both kubernetes/apimachinery and kubernetes/client-go@release-4.0
kubernetes/apiextensions-server@release-1.7 will need to update it’s dependencies so that it is using the fixed version of kubernetes/apimachinery from the previous step.
My project will update it’s dependencies to reflect the above changes.
A new patch version of kubernetes/kubernetes will need to be cut so that kubernetes/kubernetes#52545 is reflected.
Update my cluster to use 1.7.new and then everything should work.

frankgreco on Oct 4, 2017