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
