CRD age does not change from <invalid> as soon as it becomes Established

[vadimeisenbergibm]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug

What happened:
When deploying https://github.com/istio/istio/blob/master/install/kubernetes/istio.yaml on minikube, I get the following errors:

unable to recognize "install/kubernetes/istio.yaml": no matches for config.istio.io/, Kind=attributemanifest

for each of the custom resources specified in https://github.com/istio/istio/blob/master/install/kubernetes/istio.yaml

Running kubernetes get crd returns:

NAME                                  AGE
attributemanifests.config.istio.io    <invalid>

After several seconds, kubernetes get crd returns valid age for the CRDs. Then the custom resources are added successfully.

What you expected to happen:
I expect that it should be explicitly documented: can custom resources be added immediately after their CRDs? Or the user should wait until kubernetes get crd returns valid age.

How to reproduce it (as minimally and precisely as possible):
Deploy https://github.com/istio/istio/blob/master/install/kubernetes/istio.yaml on a minikube with limited resources, so it will take time for the CRDs to become valid.

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): 1.8.0
• Cloud provider or hardware configuration: Minikube 0.23.0
• OS (e.g. from /etc/os-release): Minikube on Virtual Box on Mac OS
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[vadimeisenbergibm]

/sig api-machinery

[ncdc]

It typically takes a short amount of time for the server to process a new CRD before you can begin creating resources. You can check the CRD's status.conditions for an entry in the array where type equals Established.

cc @deads2k @sttts @enisoc @nikhita - do we have this documented anywhere?

[vadimeisenbergibm]

@ncdc So what are the users of kubectl advised to do with regard to new CRDs and their resources? Define CRDs first, wait several seconds and then add resources? Or just add new CRDS and their resources, and in case of failure retry? I would like this advice to be documented somewhere.

You can check the CRD's status.conditions for an entry in the array where type equals Established

By which command can I check this?

[ncdc]

@vadimeisenbergibm

So what are the users of kubectl advised to do with regard to new CRDs and their resources? Define CRDs first, wait several seconds and then add resources? Or just add new CRDS and their resources, and in case of failure retry? I would like this advice to be documented somewhere.

I'm not sure what our guidance is beyond waiting. You could also programmatically poll/watch the CRD and wait for it to be established. cc @kubernetes/sig-api-machinery-misc for increased visibility & guidance

By which command can I check this?

Here is a sample I just ran:

$ get crd/backups.ark.heptio.com -o jsonpath='{.status.conditions[?(.type == "Established")].status}{"\n"}'
True

[sttts]

https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ does not document this, but should. PR welcome.

[sttts]

And of course there is no connnection to Minikube, but it is like that by design on every cluster.

[nikhita]

For the docs: kubernetes/website#6660.

[nikhita]

/assign