+1 to release Helm charts as part of a Polaris release (with other artifacts).
If we can create a repo for helm charts, most of the ASF projects providing helm charts do that on their website and/or main repo via dist.apache.org (that is used also for download.apache.org and archive.apache.org). I think we should use dist.apache.org for helm charts releases. Regards JB Le ven. 31 janv. 2025 à 11:04, Alex Dutra <alex.du...@dremio.com.invalid> a écrit : > 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 > >> > > >> > > >
