Does voting needs to happen for "releasing" the Helm chart ? Do we any guidelines from the ASF around releasing Helm Chart & Dockerfile?
On Sat, Sep 5, 2020, 17:36 Matt Sicker <boa...@gmail.com> wrote: > If packaging is similar to Docker, then our Helm charts will still > need some third party base images and such for GPL licensed system > dependencies (besides the kernel itself, there's OpenJDK which is > definitely used in plenty of projects here). The bits we build on top > of external components becomes the Apache project that is ALv2 and is > distributed through source archives with convenience binaries (in this > case, the image layers and YAML files). > > I do like the idea of having a central Apache Helm chart repo where > releases can be published. That makes it simpler for users to combine > multiple Apache charts together, too, based on my past experience with > using Helm (especially with the new decentralized charts distribution > model they've switched to). I do think it makes sense to try and > maintain the sources and such for those charts in the individual > projects since each PMC may have different workflows on how that's > created, and it makes it easier to release alongside the normal > project's releases. > > On Sat, 5 Sep 2020 at 11:13, Daniel Imberman <dimber...@apache.org> wrote: > > > > While I understand the necessity for users to have access to all source > code, I'm a bit concerned about the complexity this places on the > open-source project. Let's take Airflow as an example. If we want to use > pgbouncer in our home chart are we expected to be able to build this > external project? > > > > I think that if this is ASF policy, then maybe we need to modify the > policy to meet the current ecosystem. Helm charts are made to handle > complex deployments, and expecting a project to own every other piece of > their ecosystem is a pretty heavy burden. Is there some compromise we can > come to? Can we store certain pieces such as source code, Dockerfile, and > docker binary in some Apache cold storage to ensure they are reproduceable? > > > > Ideally I'd just like to keep the burden on project maintainers to a > minimum. This could heavily discourage projects from creating official helm > charts. > > > > > > On 2020/09/04 15:05:56, Scott Rigby <sc...@r6by.com> wrote: > > > Jarek, this is fantastic! Please let me know if I/we can help with > this. The Helm team has written tools to make some of these processes > easier, including steps to preserve former git history, and GitHub Actions > for CI (chart testing) and CD (releasing chart version packages via GitHub > release artifacts). > > > > > > Bertrand, many orgs are adopting a git repo naming convention > "helm-charts" to make this explicit. > > > > > > Fun follow-up question: a helm repo is really just an index (YAML) > file of metadata in a format the helm client expects, including links to > packaged tarballs for each immutable version of a chart. The idea of Apache > mirror hosting is on the table, one issue we have is that the GCP object > storage buckets that currently host all previous versions of stable and > incubator repo charts will be deleted after support for these repos ends on > Nov 13th ( > https://github.com/helm/charts/blob/master/README.md#deprecation-timeline). > Would it be possible for Apache to host a mirror of all these packages > (note, they are all Apache licenced), or only chart packages related to > Apache software (airflow, solr, spark, etc)? > > > > > > Scott > > > > > > On 2020/09/04 08:47:30, Jarek Potiuk <ja...@potiuk.com> wrote: > > > > Big +1 for doing this within existing ASF infrastructure. Maybe > indeed > > > > current SVN publishing a release snapshot + mirroring is the best > way. > > > > > > > > IMHO such 'released' charts do not have to have commit history at all > > > > (except 'release' commits) - just release 'snapshots' is enough. For > all > > > > the other development uses, whatever the source repository is, you > will be > > > > able too install 'development' chart from the sources. > > > > > > > > Still having clear guidelines on how to approach Docker images and > > > > 'rebuildability' by the users from sources is an important aspect > IMHO. > > > > J. > > > > > > > > pt., 4 wrz 2020, 10:15 użytkownik Bertrand Delacretaz < > > > > bdelacre...@apache.org> napisał: > > > > > > > > > Hi, > > > > > > > > > > On Fri, Sep 4, 2020 at 9:22 AM Jarek Potiuk <ja...@potiuk.com> > wrote: > > > > > > ...I think having ASF "apache/chart" for all "officially > released" helm > > > > > > charts is the best solution.... > > > > > > > > > > Sounds like a good idea but please use a more specific name, > "charts" > > > > > is very generic. > > > > > > > > > > If distributing those Helm charts does not requires more than a web > > > > > server (with some metadata files I suppose) that can probably go > in a > > > > > specific folder under https://dist.apache.org/repos/dist/release/ > > > > > > > > > > The next question is what kind of traffic is expected there, and > can > > > > > the clients which will download those Helm charts handle redirects > to > > > > > distribution mirrors? If yes the mechanism of > > > > > http://www.apache.org/dev/release-download-pages.html comes to > mind, > > > > > if you can piggyback on that mirroring infrastructure that's a big > > > > > plus IMO. > > > > > > > > > > I guess the way to move forward is for the people interested in > this > > > > > to list the technical and licensing/legal requirements on a wiki > page > > > > > or equivalent, to discuss with the ASF infrastructure team how to > best > > > > > support them. > > > > > > > > > > -Bertrand > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > -- > Matt Sicker <boa...@gmail.com> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
