orchestration order when doing helm install

[jchauncey]

So I found a group of manifests for building an elastic search cluster using their best practices. https://github.com/pires/kubernetes-elasticsearch-cluster

The problem is you need to running the kubectl create -f commands in a particular order for the cluster to get setup correctly. I was wondering how we might do this with helm.

My first idea was sort the list of manifests and if you need them run in a particular order you can do

• 1_mymanifest.yaml
• 2_myothermanifest.yaml

[jchauncey]

So the other part of this is when you need certain things to be in a running state before you start other pods, rcs, or services. For instance -

kubectl create -f service-account.yaml
kubectl create -f es-discovery-svc.yaml
kubectl create -f es-svc.yaml
kubectl create -f es-master-rc.yaml

Wait until es-master is provisioned, and

kubectl create -f es-client-rc.yaml

Wait until es-client is provisioned, and

kubectl create -f es-data-rc.yaml

Wait until es-data is provisioned.

(This is taken from the above repo's readme)

[jchauncey]

Whenever we create a replication controller or pod if we waited until that was running before we moved to the next manifest I think that would help.

[rimusz]

or have some config.yaml file where we list the order?

[adamreese]

@jchauncey manifests are currently uploaded in a specific order by type. Are there order restrictions for the same type of manifest? svc-a.yaml before svc-e.yaml but not after svc-c.yaml kind of a thing?

[jchauncey]

The above scenario is what I am trying to accomplish. I need to start 3 replication controllers in a very particular order and can only proceed when it is in the running state.

[gabrtv]

I'm strongly against this kind of first-class orchestration in Helm.

Kubernetes is a declarative system. Users provide manifests that define desired state and Kubernetes converges the current state accordingly. If the workloads in question don't support this model because they require specific ordering, that means the workloads do not support a declarative model. In this case, the focus should be on fixing the workloads to support orderless installation via logic inside the pods.

I know this has the potential to a significant amount of work to Helm Chart authors for services like ES, etcd and others which require a "discovery/bootstrap" process -- but this is solvable inside the container images. See redis-cluster chart as an example.

[technosophos]

I agree with @gabrtv. The design of Kubernetes suggests that we shouldn't have to orchestrate things quite this way.

What we did with the etcd pod is write a bit of bootstrap code for each piece so that if they came up out of order they could recover. It's also not uncommon to see the sort of Erlang motif that if a service comes up and its environment isn't ready, it should crash and let the supervisor (in this case, Kubelet) handle restarting it.

https://github.com/deis/etcd/blob/master/boot.go#L324