Hi I'm fine having a dedicated repo for helm chart, it all depends on what we want to release: 1. If we just want to release helm charts "package", then helm charts can stay in the polaris repo (as so part of the source distribution) 2. if we want to release a complete different source distribution and package for Helm Charts, then we can have a complete separate repository.
Apache projects use both. For instance, Airflow is using (1), whereas Pulsar or Ozone are using (2). If we have a consensus for a separate repo, I would suggest apache/polaris-helm-chart repository. I can create. Regards JB On Mon, Jul 14, 2025 at 1:25 PM Alexandre Dutra <adu...@apache.org> wrote: > > Hi all, > > For reference and completeness, this has also been previously > discussed in a much older thread: > https://lists.apache.org/thread/428xb6dfrmm7xgr91p2dxoy8ptcyovs2 > > So far the consensus was, as Yufei pointed out, to release the Helm > chart along with the Polaris server release (+docker images, etc.) – > mostly for the sake of simplicity. > > I confess I'm torn on the idea of separate releases and/or moving the > chart to the polaris-tools repo. I fear that the chart could quickly > lag behind Polaris itself, especially when configuration options > change. > > But if that is now the preferred option, I'm fine with that. > > Thanks, > Alex > > > On Sun, Jul 13, 2025 at 5:27 AM Yong Zheng <yzh...@apache.org> wrote: > > > > I also likes the idea of moving the chart to a different repo (some obvious > > downsize are we will need to move some work around and duplicate some build > > pipeline etc.). Also, another thing we will loss is the published helm doc > > (assuming we still want it, otherwise, just ask people to get the info from > > README.md from git repo). Other than these, I don't have a concern. > > > > On 2025/07/12 11:21:53 Robert Stupp wrote: > > > If the consensus is to have a different release cadences for the > > > Polars helm chart and Polaris "server", I propose to move the helm > > > charts to polaris-tools. One difference between the two repos is that > > > the "main" repo eventually gets (semi) automatic releases that might > > > get confused with rather manually driven helm-chart releases (it will > > > have to use and check against Git tags and potentially version > > > branches). Therefore the polaris-tools repo sounds more appropriate, > > > because there are already multiple "sub projects". > > > > > > Another reason to move the helm-charts to polaris-tools is that the > > > helm-charts, if released independently, become suitable for multiple > > > Polaris versions, which requires tests/CI against multiple Polaris > > > versions. Letting pretty much every change to the "main" repository > > > trigger CI for a potentially big helm-chart/Polaris test-matrix seems > > > to be an unnecessary waste of CI time. In polaris-tools, all CI jobs > > > are "scoped" to a particular "root path". > > > > > > Different release cadences also mean to maintain a "compatibility > > > matrix", not immediately, but in the (near?) future. > > > > > > Thoughts? > > > > > > On Sat, Jul 12, 2025 at 9:08 AM Yufei Gu <flyrain...@gmail.com> wrote: > > > > > > > > Sounds good. I think Apache Airflow did the exact same thing by > > > > publishing > > > > both Helm Chart source and Helm Chart binary package. We still need to > > > > figure out a few things: > > > > 1. What does the Helm Chart version look like? > > > > 2. Publishing a version map between Helm Chart and Polaris server as the > > > > part of Helm Chart doc. For example, Helm Chart version 1.2.0 works with > > > > Polaris server 0.9.0, 1.0.0, and 1.1.0. > > > > 3. What's the default docker image tag? I'd suggest using the latest > > > > Polaris release version(e.g., 1.0.0-incubating) at the time the Helm > > > > Chart > > > > was published. > > > > 4. Location would be easy to decide, we can continue to publish it to > > > > dist.apache.org as 1.0.0-incubating did. > > > > > > > > If we decide to release the Helm chart on its own cadence, we don't > > > > need a > > > > nightly Helm Chart release at this time. > > > > > > > > Yufei > > > > > > > > > > > > On Fri, Jul 11, 2025 at 11:32 PM Jean-Baptiste Onofré > > > > <j...@nanthrax.net> > > > > wrote: > > > > > > > > > Hi > > > > > > > > > > It's not a problem for me to release "part" of Polaris like Helm > > > > > chart. > > > > > > > > > > However, the release has to be "ASF valid", meaning that the release > > > > > needs to include source distribution. Today, we don't have source > > > > > distribution only for Helm chart (it's global source distribution > > > > > including Helm sources). > > > > > So, I propose to include a source tar gradle task in Helm chart (with > > > > > signing and checksum). If we do that, no problem. I can take a crack > > > > > on this :) > > > > > > > > > > Regards > > > > > JB > > > > > > > > > > On Sat, Jul 12, 2025 at 1:30 AM Yufei Gu <flyrain...@gmail.com> wrote: > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > While testing the freshly-minted 1.0.0-incubating release, we > > > > > > noticed > > > > > > something odd: the Polaris release has relational-jdbc persistence, > > > > > > yet > > > > > the > > > > > > Helm chart only understands the legacy eclipselink. Here is the > > > > > > issue: > > > > > > https://github.com/apache/polaris/issues/2030. > > > > > > > > > > > > We previously made the decision to publish Helm Chart with Polaris > > > > > > src > > > > > and > > > > > > bin, check the ML thread: > > > > > > https://lists.apache.org/thread/d1vf7xpn6nkzp8gbh417m8qb58tkpcqz. > > > > > > We may > > > > > > revisit the approach. I think it makes more sense to release the > > > > > > Helm > > > > > chart > > > > > > on its own cadence. Not all Polaris users need Helm charts, plus > > > > > > Helm > > > > > chart > > > > > > tweaking happens commonly between Polaris server releases. WDYT? > > > > > > > > > > > > Meanwhile, we can start to release the nightly Helm Chart as a quick > > > > > > solution for any users trying the new release with JDBC backend. > > > > > > Thoughts > > > > > > and volunteers for this one? > > > > > > > > > > > > Yufei > > > > > > > >
