Hi again, We also need to discuss hosting Helm charts. We cannot release a Helm chart if there is no repository available to host our charts.
There are several ways of achieving this, but one simple solution would be to host our charts on a separate GitHub repository. This alone can be enough for users to be able to "helm pull" our charts. Optionally, we can also reference the chart on https://artifacthub.io/ to reach an even broader audience. I don't know, however, what it takes for the ASF to give us a separate GitHub repo. We may want to explore what other Apache projects are doing. AirFlow for example seems to have transformed their website, airflow.apache.org, into a Helm repo: - The index.yaml file is available at the root of the website: https://airflow.apache.org/index.yaml – this means, users can add the repo with "helm repo add airflow https://airflow.apache.org"; – which looks very nice. - The chart URLs in the index.yaml file point to downloads.apache.org or archive.apache.org, indicating that they are probably pushing the chart packages to ASF servers. - The documentation is here: https://airflow.apache.org/docs/helm-chart/stable/index.html. Also worth noticing: AirFlow seems to be using separate versioning schemes for the chart and the app, while still hosting the chart and the app together: https://github.com/apache/airflow/blob/2.10.4/chart/Chart.yaml#L22-L23. Anyways, I'm curious to hear what others think about this topic as well. Thanks, Alex On Fri, Jan 31, 2025 at 10:42 AM Alex Dutra <alex.du...@dremio.com> wrote: > Hi, > > Let me try to shed some context. Helm chart versioning was designed to be > independent of application versioning. This is why the Chart.yaml > descriptor provides two fields: > > - "version" is the Helm chart version, and follows semver strictly > - "appVersion" is the target application version (optional, free form) > > And even if this seems to tie a Helm chart version X to an application > version N, "appVersion" is just a hint. A Helm chart version X is capable > of deploying target application versions in a range of M to N – because > ultimately what counts is the Docker images being deployed, and these can > have any version as long as they are compatible. The range boundaries are > dictated solely by changes in the application configuration interface that > would make the Helm chart unsuitable for use with it: e.g. if the Helm > chart configures the application with environment variable FOO, but all of > a sudden the variable is renamed to BAR in version N, then we have an > incompatibility between chart X and app N. > > So what Dmitri proposes makes total sense generally speaking. > > It is true though, that this flexibility may introduce some confusion for > users. Many users tend to consider that the Helm chart version X must equal > the application version N, and they even install a new chart every time > they upgrade their deployments. That's not required per se, but is often > seen in the field: both the Helm chart and the docker images get upgraded > simultaneously. > > In any case, we also need to take into account some practicalities: the > Helm chart currently lives in the same repo as Polaris itself. This may or > may not be the best option, but it is what we have today. Because of that, > it's a lot easier for us if we consider that releasing Polaris entails > releasing the Helm chart as well. > > In the light of this, I am more in favor of releasing the Helm chart along > with every binary release, using the same versioning scheme for both the > Docker images, the distribution binaries, and the Helm chart. Granted, more > often than not, the Helm chart will be released as X+1, with no actual > changes in it; IOW, chart version X would be identical to X+1. But if > that's a problem, I'd argue that the Helm chart should be moved to a > separate repo. > > Hope that makes sense, > > Alex > > On Thu, Jan 30, 2025 at 8:01 PM Eric Maynard <eric.w.mayn...@gmail.com> > wrote: > >> That seems like it could confuse users to me. The docs will refer to >> feature X being in version Y of the application — how do I connect that to >> a helm chart? Or if I want to go read the source code that’s connected to >> the helm chart I’m running, where do I find that mapping? >> >> Couldn’t we just cut a patch version of the source and do a release >> (binary >> + helm chart) so that there’s always a clear coupling? >> >> On Thu, Jan 30, 2025 at 10:44 AM Dmitri Bourlatchkov <di...@apache.org> >> wrote: >> >> > Hi All, >> > >> > PR 912 [1] prompted this discussion. >> > >> > I believe it is valuable to release helm charts separately from the main >> > source / binary bundle primarily because the lifecycle of the charts is >> > different from java code and often requires changes that are not >> connected >> > to service implementations. >> > >> > I'd like to propose: >> > >> > * Each binary java release to have a matching Helm chart release with >> > possibly a different version. >> > >> > * Allow independent helm chart releases. >> > >> > * Source releases (e.g. 0.9) do not have to be connected to any >> particular >> > helm chart release. >> > >> > Thoughts? >> > >> > [1] https://github.com/apache/polaris/pull/912 >> > >> >
