Provide helm charts for Envoy Gateway installation

[bmetzdorf]

Would be great to have helm charts.

Question for you:

Should they follow the same release cycle and versioning as Envoy Gateway itself? That would make it easy to qualify them and track changes. Many other projects don't do that and then the charts sometimes rot a bit.

[arkodg]

thanks for raising this issue, agree, the charts should be published with every release.
also relates to #479

[bmetzdorf]

@arkodg sounds great!

Maybe we can use something like https://github.com/arttor/helmify for this?

[Xunzhuo]

I will work on this, so I would like to assign this:)

[stevehipwell]

I'd like to suggest that the Helm chart version isn't tied to the Gateway version so it can also be release without a corresponding Gateway release. This isn't something that is generally possible and even less likely to be successful for a pre-release product with a brand new Helm chart.

[arkodg]

@stevehipwell we release a latest release on every commit to main
https://github.com/envoyproxy/gateway/releases/tag/latest
users should be able to access bleeding edge Helm Charts from above artifcacts if they need to.
or we could also push them to a helm registry on every merge

[stevehipwell]

@arkodg would it not be better for that use case to be met by changing the chart image tag? To correctly lifecycle a chart you need a manual step after the image has been released to update Chart.yaml to set the new app and chart version (you would also need to update values.yaml if the image tag isn't based on the app version).

[bmetzdorf]

@stevehipwell You make good points. We could explicitly version the Chart independently. But we would have to track which Chart versions are compatible with which EG versions (e.g have a separate Changelog for the Helm chart). I'm a fan of explicit versions (the Chart version in Chart.yaml).

Another (maybe not so standard) approach could be this: Envoy Gateway 0.3.x includes Chart versions 0.3.y, allowing for independent Chart updates while still expressing general compatibility. Just an idea..

[arkodg]

@arkodg would it not be better for that use case to be met by changing the chart image tag? To correctly lifecycle a chart you need a manual step after the image has been released to update Chart.yaml to set the new app and chart version (you would also need to update values.yaml if the image tag isn't based on the app version).

@stevehipwell we have a similar image updating strategy for our kube yamls (eg. here), so doing something similar for helm cherts before publishing it shouldnt be too hard.
Today, all the artifacts pushed by this project (container images, GH releases containing kube install YAMLs) are based off the same version, adding another version only for charts will add complexity to the tooling .
The latest tag will always be released to access bleeding edge changes.

[stevehipwell]

@arkodg a Helm chart is effectively another application, unlike manifests which are part of the primary application and can be versioned according. I'm yet to see a scenario where an application has had it's version implicitly tied to a dependency work out (app to app, chart to app, etc). I think you'd add more complexity trying to keep the versions in sync than by having a different chart version like most of the rest of the CNCF landscape.

[arkodg]

thanks for raising these points @stevehipwell , imho this project should follow what the rest of the landscape is doing w/o incurring too much complexity
cc @Xunzhuo

[Xunzhuo]

/stale cancel

[haq204]

following up on this to see if there was a final decision made on supporting a Helm chart. If so, could we possibly add it to 0.4.0?

[stevehipwell]

I'm happy to contribute a Helm chart and the associated automation. By default this would have the following characteristics (will edit if I've forgotten any).

• Independently versioned Helm chart
• Chart CHANGELOG
• Curated releases (no release spam)
• GH pages repo
• OCI repo (could be GHCR or alternative)
• Cosign signature on OCI chart
• Artifact Hub config
• Chart changes listed in GH release (not flagged as latest so no confusion with binary)
• Testing & conformance automation

[arkodg]

hey @haq204 @stevehipwell Ive added this to the 0.4.0 Roadmap #987
@stevehipwell thanks for volunteering to work on this ! its currently assigned to @Xunzhuo, lets wait to hear back from him

[Xunzhuo]

Thanks @stevehipwell, it`s already WIP with a draft PR, I plan to work on it in v0.4.0.

[stevehipwell]

@Xunzhuo let me know if you want any help with the automation?

[Xunzhuo]

@Xunzhuo let me know if you want any help with the automation?

Hi @stevehipwell, sorry for the late reply. I start to work on this task now, I open an issue in #1072. Because this requires some refactors to toolings and conformance tests of EG. So I will take this part and send a main PR for it: #651. As for the automations part, I will send another PR for it, I will have a try, but I know you are pretty good at it. If I meet some troubles hope you can help me or I can transfer the automation task to you.

Thanks again for your interest and help in this part! @stevehipwell