Linkerd2: Making Linkerd configuration more like Helm

[Pothulapati]

Feature Request

With the current Linkerd CLI architecture, There is always a question on which configuration goes into CLI and Helm. This issue aims to make the LInkerd CLI install and upgrade flow more like Helm, and thus making the CLI's install and upgrade flow more simpler and making it easy to add more configuration options.

The CLI's install and upgrade flow is pretty similar to Helm (atleast the UX), with our own way of storing configuration, etc. Why not use Helm internally and make the whole flow simpler?

What problem are you trying to solve?

• Remove the difference between Helm and CLI, especially on the state management. so that we only have a single lifecycle to maintain.
• Make the install and upgrade flow simpler. Currently, this workflow is scattered across multiple steps with configuration scattered across flags, configs, etc. This should also touch add-ons, as we use linkerd-config-addons to store state.
• Allow advanced configuration through the CLI. so that we don't have to maintain/worry on which configuration is allowed on which tool. This also helps us have a single configuration doc both with Helm and CLI.

How should the problem be solved?

Use Helm internally to perform the install (along with storing state) and upgrades.

This does not mean that we will remove all the current CLI flags, and linkerd-config, we can still have them but de-couple the upgrade logic from it.

How would users interact with this feature?

Users will interact with the CLI in the same current manner, but they will have a extra set of flags especially --set & -f just like Helm, and they will be able to use all the configuration that is allowed through Helm with the CLI.

The aim is to keep the current UX and interactions intact, but swap the install and upgrade logic with Helm.

cc: @alpeb @grampelberg @adleong @ihcsim

[olix0r]

What problem are you trying to solve?

• Remove the architectural difference between Helm and CLI, by using Helm internally to not only render but also perform the install and upgrades. Thus offloading configuration state storage and upgrades to Helm.
• Make it easy to add new configuration options, by just adding a Helm option and the relevant update in Helm templates.
• This also makes the add-on configuration management simple, as there is no need for linkerd-config-addons with this, as the state would be managed by Helm itself.

Not to nitpick, but these are all side-effects. What are the problems, framed independently of your proposed solution?

[Pothulapati]

@olix0r That makes sense, Updated the problems to not include anything related to the solution!

[adleong]

Let me see if I understand what you are proposing:

We would replace the structure of the linkerd-config configmap and replace its contents with the Helm values.yaml. During linkerd install we would generate a Values.yaml based on the existing flags plus any values set with --set and -f use that to render the linkerd install chart, and store it in the configmap. During upgrade we would load the Values.yaml from the configmap, apply any updates to it based on the upgrade flags, and render the chart with the updated values.

Does that sound right?

I do think this does sound simpler than what we do today.

Some questions to think about:

What does the transition period look like when users are upgrading from a release that uses the existing config structure? Is there a way to convert a linkerd-config into a values.yaml that preserves all of the configuration?

[ihcsim]

If we want to make the CLI _more like_ Helm, why not just remove install and upgrade entirely, and let Helm 3 manage the installation/upgrade lifecycle? Not saying it's the right way, just want to explore what's possible. Up till now, we have been regarding Helm as the advance use case. But from what I gather, most users end up using Helm either directly or with IaC tools like Terraform, for their production control plane.

Sounds to me like the issue here is that the CLI code/flags/config are getting harder to maintain and keep in-sync with the Helm charts, in light of the current ongoing add-on work.

[Pothulapati]

As me and @adleong discussed in offline chat, My suggestion was to use the existing templates, and _not remove/replace_ linkerd-config (but we can make it more simpler if we are going to take this attempt) but use Helm install/upgrade logic for the CLI too and this would make upgrades simpler as values.yaml is stored automatically by Helm as a secret in k8s and that would remove CLI from doing any of the upgrade things.

This also opens the gate to make the configuration options in CLI more simpler (code wise) and also make advance configuration simpler using --set, -f flags just like Helm

If we want to make the CLI more like Helm, why not just remove install and upgrade entirely, and let Helm 3 manage the installation/upgrade lifecycle? Not saying it's the right way, just want to explore what's possible. Up till now, we have been regarding Helm as the advance use case. But from what I gather, most users end up using Helm either directly or with IaC tools like Terraform, for their production control plane.

@ihcsim I don't think removing install and upgrade commands in the CLI is a good option as a lot of users use it already and it should not be hard to wrap Helm internally under the CLI. I would even go further and say, we should not even remove the current configuration options from the CLI, as it would break a lot of users.

What does the transition period look like when users are upgrading from a release that uses the existing config structure? Is there a way to convert a linkerd-config into a values.yaml that preserves all of the configuration?

Definitely a very important question to think about. This is the reason why I did not suggest to change linkerd-config as this allows us to add one more pre-step before calling helm upgrade in CLI, to convert config options into Values.yaml and pass it to the Helm Upgrade logic. We can support this in the initial version of doing this and once we release the next version, we can remove this step too, and this allows us to simplify linkerd-config. What do you all think about this?

[adleong]

In case we needed any more motivation to simplify the install/upgrade/configuration code, @Matei207 and I both just broke our respective brains trying to figure out how flags, options, values, and configs all interact: https://github.com/linkerd/linkerd2/pull/4864

The current situation is just way too complicated.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.