Helm Subchart order of execution in an umbrella chart

Question

I have an umbrella chart with multiple sub-charts, I simply want to make sure that subchart1 runs before subchart2, etc. How can we define the order of subchart execution?

Seems like hook-weights only apply relative to the chart that declares them.

Answer 1

Here is a part of the Helm documentation related to execution order of charts:

The above sections explain how to specify chart dependencies, but how does this affect chart installation using helm install and helm upgrade?

Suppose that a chart named "A" creates the following Kubernetes objects

namespace "A-Namespace"
statefulset "A-StatefulSet"
service "A-Service"

Furthermore, A is dependent on chart B that creates objects

namespace "B-Namespace"
replicaset "B-ReplicaSet"
service "B-Service"

After installation/upgrade of chart A a single Helm release is created/modified. The release will create/update all of the above Kubernetes objects in the following order:

A-Namespace
B-Namespace
A-StatefulSet
B-ReplicaSet
A-Service
B-Service

This is because when Helm installs/upgrades charts, the Kubernetes objects from the charts and all its dependencies are aggregrated into a single set; then sorted by type followed by name; and then created/updated in that order.
Hence a single release is created with all the objects for the chart and its dependencies.

The install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go (see the Helm source file).

Part of helm/kind_sorder.go is related to install charts:

var InstallOrder SortOrder = []string{
    "Namespace",
    "ResourceQuota",
    "LimitRange",
    "PodSecurityPolicy",
    "Secret",
    "ConfigMap",
    "StorageClass",
    "PersistentVolume",
    "PersistentVolumeClaim",
    "ServiceAccount",
    "CustomResourceDefinition",
    "ClusterRole",
    "ClusterRoleBinding",
    "Role",
    "RoleBinding",
    "Service",
    "DaemonSet",
    "Pod",
    "ReplicationController",
    "ReplicaSet",
    "Deployment",
    "StatefulSet",
    "Job",
    "CronJob",
    "Ingress",
    "APIService",
}

There is a workaround, that can change the default behaviour, shared by elementalvoid in this issue:

I've been setting my services, secrets, and configmaps as pre-install hooks to achieve this behavior.

Example:

apiVersion: v1
kind: Service
metadata:
  name: foo
  annotations:
    "helm.sh/hook": "pre-install"

--

It is possible to define a weight for a hook which will help build a deterministic executing order. Weights are defined using the following annotation:

  annotations:
    "helm.sh/hook-weight": "5"

Hook weights can be positive or negative numbers but must be represented as strings. When Tiller starts the execution cycle of hooks of a particular Kind it will sort those hooks in ascending order.

More detailed information about hooks can be found here and in source file hooks.go

Answer 2

You cannot make an order, and I don't think you will need it. You can rely on health checks, so if one chart depends on another, it will probably fail and restart until health check passes.

Answer 3

While you cannot make an order, you can use Init Containers to validate your Pods have everything they need to run before actually running them: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/