Linkerd-addons.md

So, Add-on Model is planned to be done using helm charts as the underlying tool. The following constraints are present because of that:

• Sub-charts will live under charts/add-ons as new Helm charts with similar format and templating. As helm supports URL as the repo path for add-ons, They can also later be moved out-of-tree totally.
• The values of the sub-charts will be overriden by using the name of the add-on field in the parent's i.e linkerd2's values.yaml. These values are considered the defaults and can be overriden using cli or a new values file. charts/add-ons/grafana/values.yaml can left out empty so that we can maintain the config centrally.
• The requirements.yaml will be updated to have the dependencies. Ex:

dependencies:
- name: partials
  version: 0.1.0
  repository: file://../partials
- name: grafana
  version: 0.1.0
  repository: file://../add-ons/grafana
  condition: grafana.enabled 

The condition field is used like a toggle, to set the default value. If the condition is false, the sub-charts are not included. This field will point to the enabled field of the corresponding add-on in values.yaml. It's important that all the add-ons follow the same model.

• If the installation is done through Helm, it handles upgrades, etc everything.

Now, we have to replicate the same model using the linkerd CLI. like we already do similar stuff for linkerd charts. The following aspects are to be considered:

• Add-On Config

How does the CLI know about the templates of the sub-charts? Should it also maintain them? or just get those details from requirements.yaml?

IMO, We should have a similar config for add-ons in values.go, rather than reading from requirements.yaml about the add-on. Example:

type (
	// Values contains the top-level elements in the Helm charts
	Values struct {
		Stage                       string            `json:"stage"`
		ControllerImage             string            `json:"controllerImage"`
        .
        .
        .

		// Add-Ons For Linkerd
		Grafana *add_ons.Grafana `json:"grafana"`
	}

This follows the already exisitng pattern of having config in values.yaml, and relevant fields in values.go. Thus allowing us to get the defaults, perform over-writes, and storing those configs for upgrades.

• Overriding Values

The Values struct will have the default values.

By Helm, Users can always pass a new values.yaml and override the defaults. This overriden values file can contain the fields of the add-ons and will work the same.

For Linkerd Install, How should the add-on values be over-written? I was thinking, we should allow users to perform linkerd install --grafana values.yaml. We will use this yaml and overwrite the default values.

Is there a better approach rather than passing values? We could do linkerd install --grafana --grafana.image,etc but this would add a lot of installOptions.WDYT?

• Handling Upgrades

The add-ons Values should be stored somehewhere. So that we can retrieve and update them, for handing upgrades. This can be done by adding another field in linkerd-config cm. Something Like

Data
====
global:
----
...

install:
----
{"cliVersion":"edge-19.12.3","flags":[]}

proxy:
----
{"proxyImage":{"imageName":"gcr.io/linkerd-io/proxy","pullPolicy":"IfNotPresent"},"proxyInitImage":{"imageName":"gcr.io/linkerd-io/proxy-init","pullPolicy":"IfNotPresent"},"controlPort":{"port":4190},"ignoreInboundPorts":[],"ignoreOutboundPorts":[],"inboundPort":{"port":4143},"adminPort":{"port":4191},"outboundPort":{"port":4140},"resource":{"requestCpu":"","requestMemory":"","limitCpu":"","limitMemory":""},"proxyUid":"2102","logLevel":{"level":"warn,linkerd2_proxy=info"},"disableExternalProfiles":true,"proxyVersion":"edge-19.12.3","proxyInitImageVersion":"v1.2.0"}

add-ons:
---
{"name": "grafana", "image":""}{}

For Upgrades, this config-map will be parsed and all the add-ons that are present will be overriden with this config.

• Handling HA for add-ons

Add-Ons can also be highly-available. This can just work by specificying relavant values for add-ons in values-ha.yaml. The same will work by using --ha flag through cli.