Agones: Move support from Helm 2 ➡ Helm 3

[markmandel]

Helm 3 was released in Nov 2019, and has several advantages over Helm 2 (No more Tiller! 🙌)

At some point, we should switch over, but it's unclear when that should happen.

The questions I have for the community to help drive this decision:

• Are you actively wishing to move to Helm 3?
• If Agones does make a breaking change switch to Helm 3, is that going to be an issue for you?
• Has anyone already moved to Helm 3, and is the current chart still working for you?

Feedback (and any other questions people think are relevant), are appreciated.

[steven-supersolid]

We're using Google Cloud Shell to deploy which now comes with Helm 2 so we would need to upgrade, although that shouldn't be a problem.

Helm 2 is now in maintenance mode:
https://helm.sh/blog/2019-10-22-helm-2150-released/

The maintenance schedule is mentioned in the post:

6 months after Helm 3’s public release, Helm 2 will stop accepting bug fixes. Only security issues will be accepted.
12 months after Helm 3’s public release, support for Helm 2 will formally end.

The bug fix window has since been extended to 8 months:
https://helm.sh/blog/covid-19-extending-helm-v2-bug-fixes/

Key dates:
August 13th 2020 - only security fixes from this point
November 13th 2020 - support ends

[danieloliveira079]

Hi there,

I am not sure how much that would help but I've managed to install Agones with Helm3 using the current charts. A few considerations though:

• It was installed on a fresh provisioned local Kubernetes 1.14.10 cluster created using Kind.
• I never had Helm2 installed on my laptop and installed the latest Helm v3.1.0 just before trying it.
• I followed the migration steps described on https://github.com/helm/helm-2to3 and apparently, nothing was changed in regards to the Agones charts content. Running git diff showed nothing. The only issue I got was a complaining from helm saying that I didn't have some folders like starters and repository. However, after creating those 2 folders manually the issue was gone. That happened possibly because I didn't have Helm2 installed.
• Installation command changed a bit. The following command works: helm install --namespace agones-system my-release agones/agones. Instead of helm install --name my-release --namespace agones-system agones/agones. The flag --name has been removed from the helm install command.

Considerations:

• The command repo add agones https://agones.dev/chart/stable is still valid.
• The new installation command also works using an Agones specific version helm install --namespace agones-system my-release agones/agones --version 1.5.0-rc.
• The uninstall/delete command changed from helm delete my-release to helm uninstall my-release --namespace agones-system. Release names are namespace scoped now.
• I've not tested helm upgrade. Consequently, I don't know what would be the impact on a previously installed Agones services.
• After installing Agones I've tested by deploying the Simple UDP Server following https://agones.dev/site/docs/getting-started/create-gameserver/. It worked as expected.

References:
https://v3.helm.sh/docs/topics/v2_v3_migration/
https://github.com/helm/helm-2to3

It would be great is someone else could validate the information presented above.

Possibly an addition to the current https://agones.dev/site/docs/installation/install-agones/helm/ guide could cover the syntax for both versions:

• Helm2:
  
  
  
  • Install: helm install --name my-release --namespace agones-system agones/agones
  
  
  • Uninstall/Delete: helm delete my-release
  
  

• Helm3:
  
  
  
  • Install: helm install --namespace agones-system my-release agones/agones
  
  
  • Uninstall/Delete: helm uninstall my-release --namespace agones-system
  
  

But I believe this is based on the decision of which Helm version is going to be officially supported by the Agones project. Maybe a period of [DEPRECATION WARNING] would give to the users some time to adapt and update other charts they may have to install among the Agones services within the same cluster.

My conclusion at this point is that if the user is willing to start using Helm3 straight, there is no impediment from a Helm Charts perspective.

Let me know if you need help testing or updating documentation.

[aLekSer]

@danieloliveira079 thank you for completing this investigation and good level of details.
I wish to rewrite Terraform configs to see if this would solve various issues with helm module.

[markmandel]

Sounds like we should update our documentation to something similar to what cert-manager does:
https://cert-manager.io/docs/installation/kubernetes/#steps

Wherein it has both command available.

The question for us developers is probably which platform do we _test_ on in our build tools. It probably makes sense to switch to Helm 3 in the near future, and also make a note on the docs on which version is better tested.

[markmandel]

I would recommend the following changes:

• [x] Update the docs to include instructions for both Helm 2 and Helm 3
• [ ] Migrate our dev and e2e tooling to Helm 3
• [x] Make a note on our Helm installation page that we are actively testing against 3, and not 2, but 2 should still work, but we encourage you to ugrade.
• [x] Update Terraform moving to helm3
  
  
  
  • [x] Update Terraform docs.
  
  

[markmandel]

Starting working on this :+1:

[markmandel]

Fun question - do you want me to (try) and make it such that helm2 + helm3 e2e tests can live side by side, or we happy for me to hand hold e2e tests a bit while we make the transition, and I can break things as we go?

Opinions?

[aLekSer]

Can you please provide more details? And how long you expect the things would be broken in the second case?

[markmandel]

e2e tests would likely consistently fail as the PR's with Helm2 were conflicting with Helm3

So until the PR is merged, and we update the old PR's to the new Helm, it's quite likely PRs would fail while waiting on the Helm3 update to propogate.

We could handhold this process though, as needed. (removing helm installations after PR's with different types were pushed through)

[aLekSer]

If I got it right we should recreate the cluster for E2E tests.
https://github.com/googleforgames/agones/blob/master/build/includes/google-cloud.mk#L43

There could be an option to use two separate clusters after merging PR https://github.com/googleforgames/agones/pull/1611

I would agree with both options - handhold tests is OK if needed.

[markmandel]

Helm 3 can live alongside Helm 2 if need be -- the biggest issue would be having two installations of Agones in the cluster at any one time.

[markmandel]

WIP in the background - got the changes to dev & e2e tooling done.

Working on a helm3 folder under Terraform and updating the examples (helm 3 is so much easier! :raised_hands:). Felt it was safest to create a new folder for the helm 3 implementation, rather than (a) replacing the current helm module or (b) move the current helm module to helm2 module, and making the new one helm. Happy to take disagreeing opinions either here or on the PR.

Will start pushing this though once #1627 is merged.

I'm deliberately not update the Terraform dev/build Makefile tooling. I'd like to take a good look at that, and think about how we can remove the deployment manager script and/or make it so that TF is more often used with our dev/build system somehow. I don't think anyone is actually using those make targets at the moment (???), so I don't expect this to be an issue. Please let me know if I'm wrong.

[aLekSer]

Adding new module would be better way to switch to Helm 3.
I am using make install target more often at the moment for development, so I think adding some obsolete message to them would be great, before completely removing them.