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
