Retry kube-addons creation if kube-addons creation fails.

[ArtfulCoder]

etcd/kube-apiserver might not be up when kube-addons are being created.
added retry logic for kube-addons creation to give time for kube-apiserver & etcd to come up.

[ArtfulCoder]

@thockin PTAL

[zmerlynn]

The apiserver is supposed to be "up" by init.d ordering (see line 5). It may not be listening yet, though, so I agree there's a possible race here. We haven't had any real problems with the other add-on pods, though, except for one reported Salt race in #4357 that I couldn't reproduce. Any thoughts on why this one is special?

[ArtfulCoder]

APIServer depends on etcd, and even though APIserver maybe up, etcd may not have come up by then.
This happens more frequently, if etcd is defined as a pod and has to wait for kubelet to start it(etcd) and etcd is not a service anymore.

I think the init.d ordering doesnt help much in general, because just be cause a service is started, does not mean that it is operational. So we should use the ordering, but we cant completely rely on it.

[zmerlynn]

Got it. FWIW, the code LGTM and could use some more robustity. :)
On Mar 30, 2015 10:14 PM, "Abhi Shah" notifications@github.com wrote:

APIServer depends on etcd, and even though APIserver maybe up, etcd may
not have come up by then.
This happens, if etcd is defined as a pod and has to wait for kubelet to
start it.

—
Reply to this email directly or view it on GitHub
#6200 (comment)
.