multi-slot support

[frmadem]

The problem

It could be really helpful to have a way of rendering Helm artifacts according to a slot organization.

This issue discusses such a possiblity and the challenges it represents:

1. Multi-slots renders should be as close as posible to the renders we have now.
2. Slots should let us insert configuration in a "per-slot basis" and respect the rest of the general configuration.
3. Charts programmers must be able to chose which parts of their charts are "slotable" and which parts are not.
4. Slots should be arbitrary defined and not interfere with the general definition and deployment of the chart.

Proposal

Definitions

Slot

It is the partial configuration of a chart that translates in the rendering of particular Kubernetes artifacts created for that slot.

Ideally, a slot could be regarded as a branch of the general configuration of the chart (like a subchart inside a subchart):

# general configuration of a chart. 
image: foo

selector:
  app: example
  tier: backend

# definition of the slots
slots:
  # every slot must have an unique they, therefore we pack them in an object to ensure this. 
  feature_1: 
    # particular image for this slot
    image: foo:feature-1
  
  feature_alter_2:
    image: foo:feature-2 

  # we can define as many slots as we want

Multi-Slot render

It is a render capable of iterate over the slots object and produce a per-slot version of a particular type of artifact.

I.E, it takes a data function and a context (normally the root context) and produces as many artifacts as slots are defined.

For the data function to work, it creates a new key ".Values.Slot" where the particular configuration of the particular slot that is being rendered is placed.

This proposal contemplates the definition of the following multi-slots renders:

• deployment
• service
• ingress
• configmap
• secrets

In an example, and according to the definition of the slot we wrote lines-up:

{{- define "my-deployment.data" -}}

{{/* The render stores the slot name in the .Values.Slot.Name placeholder */}}
name: {{ .Release.Name}}-{{ .Chart.Name }}-{{ .Values.Slot.Name }}

selector: {{ .Values.selector | toYaml | nindent 2 }}
  slot: {{ .Values.Slot.Name }}

containers: 
  - name: app
    image: {{ .Values.Slot.image }}

{{- end -}}

{{ include "ph.deployment_multi_slot.render" . }}

The execution of this render should produce as many deployments as the are defined in the slots section of the values:

---
# deployment feature_1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <release>-<chart>-feature_1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
      tier: backend
      slot: feature_1
  template:
    metadata:
      labels:
        app: example
        tier: backend
        slot: feature_1
    spec:
      containers:
      - name: app
        image: foo:feature-1

---
# deployment feature_alter_2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <release>-<chart>-feature_alter_2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
      tier: backend
      slot: feature_alter_2
  template:
    metadata:
      labels:
        app: example
        tier: backend
        slot: feature_alter_2
    spec:
      containers:
      - name: app
        image: foo:feature-2

Default slot

Whenever a multi-slot render is defined, there is the problem of the default slot, i.e, the basic definition of the artifacts regardless of the particular slots we defined. In order to avoid defining always a "default" slot, we propose the multi_render always passes as a first slot the default slot and its configuration should be similar to the basic root configuration of the chart.

Then in the previous example and extra first iteration should be added:

# a default slot is firstly passed
# its .Values.Slot.Name is "default"
# its configuration is the basic values.yaml configuration

---
# deployment default
apiVersion: apps/v1
kind: Deployment
metadata:
  name: <release>-<chart>-default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
      tier: backend
      slot: default
  template:
    metadata:
      labels:
        app: example
        tier: backend
        slot: default
    spec:
      containers:
      - name: app
        image: foo  # the basic image defined in the values.yaml