helm: Adds 'aws', 'gcp', 'standalone' and ‘custom’ modes to teleport-cluster chart

[webvictim]

Updates #5582

Adds new modes to the teleport-cluster Helm chart to allow deployments as discussed in #5582.

The Helm guides and reference accompanying these changes are hosted here if it helps with review: https://teleport-docs-next-git-gus-helmdocs-gravitational.vercel.app/docs/ver/7.0/kubernetes-access/helm/guides/

Fixes #6681

[awly]

I'm not sure I understand this part.
If a branch is 7.0.0-dev, shouldn't the helm chart use 7.0.0?

[webvictim]

7.0.0-dev is what master is currently set to (when our most recent release is 6.1.3)

When we release 7.0.0, master will get updated to 8.0.0-dev, so this always needs to calculate n-1.

[awly]

But don't we publish helm charts from release branches, where the version is correct?
Publishing master chart as the previous version could cause issues, e.g. overwriting the released version of the chart

[webvictim]

No, the Helm charts are published nightly from master by a cron job in Drone.

You make a good point though, I think that if we want to tie Helm chart version to Teleport version (as per #5582) then we need to change Drone to make Helm chart releases part of the current tag/promote process instead, so that we publish a correctly versioned copy on the correct tag/branch whenever a release is made. We're trying to push people to install from https://charts.releases.teleport.dev rather than cloning master (or a tag/branch) so this makes some sense.

I've been resistant to this because it means that pushing a simple Helm chart bug fix is going to require releasing a whole new version of Teleport, which is a relatively heavyweight operation. This is really what the appVersion field is supposed to be for - i.e. you version your Helm chart completely separately to your application and then you can interchangeably use different versions of each. I think @klizhentas wanted to version them the same to reduce confusion, but it will make our release process a bit worse. I don't see a way around this if we want to inextricably tie chart version to Teleport version, though.

[awly]

Can we use the "Promote" function of Drone to trigger a Helm chart deployment, without triggering a full release?

[webvictim]

Yes, we could probably do that. The only question is what we'd be promoting - i.e. normally with Teleport releases, we promote a tag build which has DRONE_TAG set. If we want to allow promotion of other arbitrary commits/pushes then we'd have to work based on commit hash. We'd likely have to add some logic which refuses to release if the commit hash being promoted is on the master branch rather than a release branch, for example.

[webvictim]

Raised #6887 to track this

[webvictim]

@klizhentas Ping

[awly]

LGTM for now, keeping the existing release model from master.
But please consider moving helm releases to the same model as regular teleport releases, with some escape hatch to publish new changes without a full Teleport release.

[webvictim]

Needs a backport to branch/v6 to be published along with 6.2 (not strictly necessary from a Helm repo perspective, but some customers like to check out the release tag from Git and deploy the corresponding chart version)