Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
Great, thanks Dave
On Sun, Sep 6, 2020, 00:17 Dave Fisher wrote:
> Every release must be made in SVN on dist.apache.org. All other channels
> are optional and may or may not have Infra support.
>
> I view this as a request to have ComDev or Infra manage a Gitbox/Github
> repository where any PMC can publish a PMC approved Helm Chart release from
> their project.
>
> How to make a Helm Chart compliant with Apache Release Policy would part
> of the documentation.
>
> Sent from my iPhone
>
> > On Sep 5, 2020, at 3:30 PM, Kaxil Naik wrote:
> >
> >
> >>
> >> The point is that we MUST give the users possibility to (re)build those
> > images on their own if they want. We
> >
> >
> > From http://www.apache.org/legal/release-policy.html#source-packages, it
> > does not say it has to be on PyPI. I will reiterate what I said in the
> > Github issue, having a binary on PyPI is no guarantee that it will stay
> > there. Having a binary on Github releases
> > https://github.com/jbub/pgbouncer_exporter/tags also does not guarantee
> it
> > would not change. If the license are correct and the source is available
> I
> > definitely do not see this as a problem:
> >
> > Every ASF release MUST contain one or more source packages, which MUST be
> >> sufficient for a user to build and test the release provided they have
> >> access to the appropriate platform and tools.
> >
> >
> >
> >> On Sat, Sep 5, 2020 at 10:33 PM Jarek Potiuk wrote:
> >>
> >> @Matt Sicker -> agree on both, central chart repo,
> and
> >> per-project sources for charts. Though packaging is a bit different than
> >> Docker though. The packages contain tar.gz sources of the chart (which
> >> usually includes quite complex go templating logic, not just simple yaml
> >> files) and those templates include names of the images used. This makes
> >> the Helm chart much more close to the -src.tar.gz files we release now
> than
> >> to Docker Images we publish. So IMHO the .tgz part should follow the
> normal
> >> release process with voting @Kaxilnaik .
> >> Unless those are the very same sources of product that are already
> formally
> >> released. But then @Gaetan Semet previously pointed out as bad practice
> >> to bind the two together.
> >> IMHO that means that we have to vote on each Chart release. But I'd love
> >> what others think - knowing this packaging details.
> >>
> >> @ermanndimb- my point for images pointed to by the helm chart is not
> about
> >> copying full sources (I think from this discussion I realised where the
> >> main confusion was) . This is not needed. I just made a PR to show how
> this
> >> can be done with the pgbouncer-exporter. This is quite a good example
> to
> >> base our discussion on: https://github.com/apache/airflow/pull/10759
> >>
> >> The point is that we MUST give the users possibility to (re)build those
> >> images on their own if they want. They should be able to do that using:
> >>
> >> a) official base images (DockerHub has the "official image program" for
> >> platforms. openjdk, python,debian, alpine - those are all official
> images
> >> in DockerHub terms
> >> b) having access to properly licensed source code with some guarantees
> >> that it will not disappear ("official" repo, multiple forks in Github,
> >> heavily used by others, fork under "apache" organisation) .
> >> c) instructions where to find the sources and build the images
> >> (Dockerfile + necessary scripts to build the image if in case it is not
> >> straightforward). Similarly as we provide instructions on building the
> >> "product".
> >>
> >> If the first two are available but it's not obvious how the image was
> built
> >> - IMHO we need to provide the user instructions on how to build those
> >> images (ideally a script that does it automatically).
> >>
> >> This is all fulfilled by the PR above as an example:
> >> a) based on official, alpine image
> >> b) the pgbouncer code is properly licenced and we forked the sources
> >> several times to be sure it won't disappear
> >> c) we have a script that builds and publishes the image (image is
> published
> >> under apache/airflow DockerHub)
> >>
> >> IMHO - that's a very good example to show the kind of approach we can
> take,
> >> and shows that it isn't difficult to handle it well at all.
> >>
> >> The alternative that I am afraid of is - that we require our users to
> use
> >> binaries which are not "official" but maintained and controlled by
> >> 3rd-party (without a straightforward way of building the binary from
> >> official images + properly licensed sources + instructions). If we do
> not
> >> give those to the user but we simply point to a 3rd-party binary bimage
> -
> >> we both endorse the 3rd party, and introduce dependency on the
> 3rd-party.
> >> The user then has to rely on the 3rd-party to use the Airflow Helm
> Chart -
> >> which I think is a very bad idea.
> >>
> >> J.
> >>
> >>
> >>> On Sat, Sep 5, 2020 at 7:42 PM Kaxil Naik wrote:
> >>>
> >>> Does voting needs to ha
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
Every release must be made in SVN on dist.apache.org. All other channels are
optional and may or may not have Infra support.
I view this as a request to have ComDev or Infra manage a Gitbox/Github
repository where any PMC can publish a PMC approved Helm Chart release from
their project.
How to make a Helm Chart compliant with Apache Release Policy would part of the
documentation.
Sent from my iPhone
> On Sep 5, 2020, at 3:30 PM, Kaxil Naik wrote:
>
>
>>
>> The point is that we MUST give the users possibility to (re)build those
> images on their own if they want. We
>
>
> From http://www.apache.org/legal/release-policy.html#source-packages, it
> does not say it has to be on PyPI. I will reiterate what I said in the
> Github issue, having a binary on PyPI is no guarantee that it will stay
> there. Having a binary on Github releases
> https://github.com/jbub/pgbouncer_exporter/tags also does not guarantee it
> would not change. If the license are correct and the source is available I
> definitely do not see this as a problem:
>
> Every ASF release MUST contain one or more source packages, which MUST be
>> sufficient for a user to build and test the release provided they have
>> access to the appropriate platform and tools.
>
>
>
>> On Sat, Sep 5, 2020 at 10:33 PM Jarek Potiuk wrote:
>>
>> @Matt Sicker -> agree on both, central chart repo, and
>> per-project sources for charts. Though packaging is a bit different than
>> Docker though. The packages contain tar.gz sources of the chart (which
>> usually includes quite complex go templating logic, not just simple yaml
>> files) and those templates include names of the images used. This makes
>> the Helm chart much more close to the -src.tar.gz files we release now than
>> to Docker Images we publish. So IMHO the .tgz part should follow the normal
>> release process with voting @Kaxilnaik .
>> Unless those are the very same sources of product that are already formally
>> released. But then @Gaetan Semet previously pointed out as bad practice
>> to bind the two together.
>> IMHO that means that we have to vote on each Chart release. But I'd love
>> what others think - knowing this packaging details.
>>
>> @ermanndimb- my point for images pointed to by the helm chart is not about
>> copying full sources (I think from this discussion I realised where the
>> main confusion was) . This is not needed. I just made a PR to show how this
>> can be done with the pgbouncer-exporter. This is quite a good example to
>> base our discussion on: https://github.com/apache/airflow/pull/10759
>>
>> The point is that we MUST give the users possibility to (re)build those
>> images on their own if they want. They should be able to do that using:
>>
>> a) official base images (DockerHub has the "official image program" for
>> platforms. openjdk, python,debian, alpine - those are all official images
>> in DockerHub terms
>> b) having access to properly licensed source code with some guarantees
>> that it will not disappear ("official" repo, multiple forks in Github,
>> heavily used by others, fork under "apache" organisation) .
>> c) instructions where to find the sources and build the images
>> (Dockerfile + necessary scripts to build the image if in case it is not
>> straightforward). Similarly as we provide instructions on building the
>> "product".
>>
>> If the first two are available but it's not obvious how the image was built
>> - IMHO we need to provide the user instructions on how to build those
>> images (ideally a script that does it automatically).
>>
>> This is all fulfilled by the PR above as an example:
>> a) based on official, alpine image
>> b) the pgbouncer code is properly licenced and we forked the sources
>> several times to be sure it won't disappear
>> c) we have a script that builds and publishes the image (image is published
>> under apache/airflow DockerHub)
>>
>> IMHO - that's a very good example to show the kind of approach we can take,
>> and shows that it isn't difficult to handle it well at all.
>>
>> The alternative that I am afraid of is - that we require our users to use
>> binaries which are not "official" but maintained and controlled by
>> 3rd-party (without a straightforward way of building the binary from
>> official images + properly licensed sources + instructions). If we do not
>> give those to the user but we simply point to a 3rd-party binary bimage -
>> we both endorse the 3rd party, and introduce dependency on the 3rd-party.
>> The user then has to rely on the 3rd-party to use the Airflow Helm Chart -
>> which I think is a very bad idea.
>>
>> J.
>>
>>
>>> On Sat, Sep 5, 2020 at 7:42 PM Kaxil Naik wrote:
>>>
>>> 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 wrote:
>>>
If packaging is similar to Docker, then our Helm charts will still
need some third p
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
>The point is that we MUST give the users possibility to (re)build those
images on their own if they want.
>From http://www.apache.org/legal/release-policy.html#source-packages, it
does not say it has to be on PyPI. I will reiterate what I said in the
Github issue, having a binary on PyPI is no guarantee that it will stay
there. Having a binary on Github releases
https://github.com/jbub/pgbouncer_exporter/tags also does not guarantee it
would not change. If the license are correct and the source is available I
definitely do not see this as a problem:
Every ASF release MUST contain one or more source packages, which MUST be
> sufficient for a user to build and test the release provided they have
> access to the appropriate platform and tools.
On Sat, Sep 5, 2020 at 10:33 PM Jarek Potiuk wrote:
> @Matt Sicker -> agree on both, central chart repo, and
> per-project sources for charts. Though packaging is a bit different than
> Docker though. The packages contain tar.gz sources of the chart (which
> usually includes quite complex go templating logic, not just simple yaml
> files) and those templates include names of the images used. This makes
> the Helm chart much more close to the -src.tar.gz files we release now than
> to Docker Images we publish. So IMHO the .tgz part should follow the normal
> release process with voting @Kaxilnaik .
> Unless those are the very same sources of product that are already formally
> released. But then @Gaetan Semet previously pointed out as bad practice
> to bind the two together.
> IMHO that means that we have to vote on each Chart release. But I'd love
> what others think - knowing this packaging details.
>
> @ermanndimb- my point for images pointed to by the helm chart is not about
> copying full sources (I think from this discussion I realised where the
> main confusion was) . This is not needed. I just made a PR to show how this
> can be done with the pgbouncer-exporter. This is quite a good example to
> base our discussion on: https://github.com/apache/airflow/pull/10759
>
> The point is that we MUST give the users possibility to (re)build those
> images on their own if they want. They should be able to do that using:
>
> a) official base images (DockerHub has the "official image program" for
> platforms. openjdk, python,debian, alpine - those are all official images
> in DockerHub terms
> b) having access to properly licensed source code with some guarantees
> that it will not disappear ("official" repo, multiple forks in Github,
> heavily used by others, fork under "apache" organisation) .
> c) instructions where to find the sources and build the images
> (Dockerfile + necessary scripts to build the image if in case it is not
> straightforward). Similarly as we provide instructions on building the
> "product".
>
> If the first two are available but it's not obvious how the image was built
> - IMHO we need to provide the user instructions on how to build those
> images (ideally a script that does it automatically).
>
> This is all fulfilled by the PR above as an example:
> a) based on official, alpine image
> b) the pgbouncer code is properly licenced and we forked the sources
> several times to be sure it won't disappear
> c) we have a script that builds and publishes the image (image is published
> under apache/airflow DockerHub)
>
> IMHO - that's a very good example to show the kind of approach we can take,
> and shows that it isn't difficult to handle it well at all.
>
> The alternative that I am afraid of is - that we require our users to use
> binaries which are not "official" but maintained and controlled by
> 3rd-party (without a straightforward way of building the binary from
> official images + properly licensed sources + instructions). If we do not
> give those to the user but we simply point to a 3rd-party binary bimage -
> we both endorse the 3rd party, and introduce dependency on the 3rd-party.
> The user then has to rely on the 3rd-party to use the Airflow Helm Chart -
> which I think is a very bad idea.
>
> J.
>
>
> On Sat, Sep 5, 2020 at 7:42 PM Kaxil Naik wrote:
>
> > 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 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 tog
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
@Matt Sicker -> agree on both, central chart repo, and
per-project sources for charts. Though packaging is a bit different than
Docker though. The packages contain tar.gz sources of the chart (which
usually includes quite complex go templating logic, not just simple yaml
files) and those templates include names of the images used. This makes
the Helm chart much more close to the -src.tar.gz files we release now than
to Docker Images we publish. So IMHO the .tgz part should follow the normal
release process with voting @Kaxilnaik .
Unless those are the very same sources of product that are already formally
released. But then @Gaetan Semet previously pointed out as bad practice
to bind the two together.
IMHO that means that we have to vote on each Chart release. But I'd love
what others think - knowing this packaging details.
@ermanndimb- my point for images pointed to by the helm chart is not about
copying full sources (I think from this discussion I realised where the
main confusion was) . This is not needed. I just made a PR to show how this
can be done with the pgbouncer-exporter. This is quite a good example to
base our discussion on: https://github.com/apache/airflow/pull/10759
The point is that we MUST give the users possibility to (re)build those
images on their own if they want. They should be able to do that using:
a) official base images (DockerHub has the "official image program" for
platforms. openjdk, python,debian, alpine - those are all official images
in DockerHub terms
b) having access to properly licensed source code with some guarantees
that it will not disappear ("official" repo, multiple forks in Github,
heavily used by others, fork under "apache" organisation) .
c) instructions where to find the sources and build the images
(Dockerfile + necessary scripts to build the image if in case it is not
straightforward). Similarly as we provide instructions on building the
"product".
If the first two are available but it's not obvious how the image was built
- IMHO we need to provide the user instructions on how to build those
images (ideally a script that does it automatically).
This is all fulfilled by the PR above as an example:
a) based on official, alpine image
b) the pgbouncer code is properly licenced and we forked the sources
several times to be sure it won't disappear
c) we have a script that builds and publishes the image (image is published
under apache/airflow DockerHub)
IMHO - that's a very good example to show the kind of approach we can take,
and shows that it isn't difficult to handle it well at all.
The alternative that I am afraid of is - that we require our users to use
binaries which are not "official" but maintained and controlled by
3rd-party (without a straightforward way of building the binary from
official images + properly licensed sources + instructions). If we do not
give those to the user but we simply point to a 3rd-party binary bimage -
we both endorse the 3rd party, and introduce dependency on the 3rd-party.
The user then has to rely on the 3rd-party to use the Airflow Helm Chart -
which I think is a very bad idea.
J.
On Sat, Sep 5, 2020 at 7:42 PM Kaxil Naik wrote:
> 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 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
> 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 h
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
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 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 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 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 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 > 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 clie
[jira] [Closed] (COMDEV-269) GSOC 2018 OFBiz Extend AR/AP to support China accounting regulations
[ https://issues.apache.org/jira/browse/COMDEV-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Jinghai closed COMDEV-269. -- Resolution: Invalid Close now. > GSOC 2018 OFBiz Extend AR/AP to support China accounting regulations > > > Key: COMDEV-269 > URL: https://issues.apache.org/jira/browse/COMDEV-269 > Project: Community Development > Issue Type: New Feature > Components: GSoC/Mentoring ideas >Reporter: Shi Jinghai >Priority: Major > Labels: Java, OFBiz, gsoc2018 > > We can imagine business as a network, every company is a node. > In current OFBiz AR/AP model, a payment incoming to the node is AR, a payment > outgoing from the node to other one is AP. > In China accounting regulations, every company has suppliers and customers. A > payment flow between suppliers and the company is AP, no matter it's an > incoming or outgoing payment. A payment flow between the company and > customers is AR, no matter it's an incoming or outgoing payment. The pros of > China accounting regulations is it's easy to understand a company's financial > problems, purchase too much, sales too little. The cons is it's not popular > and natural. > No surprise, the balance numbers are same as the results of AR - AP are equal. > Here are the task requirements: > 1. Extend OFBiz to support China accounting regulations, OFBiz user can set a > company to use general and/or China AR/AP. > 2. The implement should be a patch against OFBiz trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[jira] [Closed] (COMDEV-270) GSOC 2018 OFBiz Onpage help tool
[ https://issues.apache.org/jira/browse/COMDEV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shi Jinghai closed COMDEV-270. -- Resolution: Invalid I agree with Jacques. This issue is no longer valid as it's for gsoc 2018. Close now. > GSOC 2018 OFBiz Onpage help tool > > > Key: COMDEV-270 > URL: https://issues.apache.org/jira/browse/COMDEV-270 > Project: Community Development > Issue Type: New Feature > Components: GSoC/Mentoring ideas >Reporter: Shi Jinghai >Priority: Critical > Labels: gsoc2018 > > Sometimes we want to tell OFBiz user that we add a new important function on > a page he/she is viewing, or help user understand the steps on a page without > leaving that page. > Obviously, JQuery-pagewalkthrough[1] is a good choice to be the front end of > onpage helps, and developers can create/edit the multi-language content of > helps in OFBiz content component. > The target of this task is to implement this Onpage help tool and several > example pages for OFBiz trunk. > > 1. [https://github.com/jwarby/jquery-pagewalkthrough] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
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 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 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 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 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 IM
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
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 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 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 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
[jira] [Commented] (COMDEV-270) GSOC 2018 OFBiz Onpage help tool
[ https://issues.apache.org/jira/browse/COMDEV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191050#comment-17191050 ] Jacques Le Roux commented on COMDEV-270: I see no reasons to not close this issue now. BTW the last contribution to https://github.com/jwarby/jquery-pagewalkthrough was 5 years ago... > GSOC 2018 OFBiz Onpage help tool > > > Key: COMDEV-270 > URL: https://issues.apache.org/jira/browse/COMDEV-270 > Project: Community Development > Issue Type: New Feature > Components: GSoC/Mentoring ideas >Reporter: Shi Jinghai >Priority: Critical > Labels: gsoc2018 > > Sometimes we want to tell OFBiz user that we add a new important function on > a page he/she is viewing, or help user understand the steps on a page without > leaving that page. > Obviously, JQuery-pagewalkthrough[1] is a good choice to be the front end of > onpage helps, and developers can create/edit the multi-language content of > helps in OFBiz content component. > The target of this task is to implement this Onpage help tool and several > example pages for OFBiz trunk. > > 1. [https://github.com/jwarby/jquery-pagewalkthrough] > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
