[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=17190956#comment-17190956 ] Rajkumar Raiyan commented on COMDEV-270: Thanks for your help > 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
[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=17190955#comment-17190955 ] Rajkumar Raiyan commented on COMDEV-270: Thanks for your help > 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
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
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
Hi, I am one of the maintainer of the Airflow Chart (stable/airflow at https://github.com/helm/charts/tree/master/stable/airflow). Our idea (described in this discussion https://github.com/apache/airflow/issues/10523) is to copy or host the current Airflow chart as it is, like a "community maintained project" but hosted at ASF somewhere. Ideally, we can continue to maintain or maybe even do some evolution on it, but the goal is to redirect users to the official Airflow Chart (Bitnami?) so new users can select the one they want, and old users can choose when to do the migration, even after november). Gaetan On 2020/09/03 21:01:12, Dave Fisher wrote: > Hi - > > Does the Helm Chart community wish to explore becoming an Apache Project > Community? > > Regards, > Dave > > Sent from my iPhone > > > On Sep 3, 2020, at 12:33 PM, Ween Jiann wrote: > > > > Hi all, > > > > The helm team has deprecated the charts repository and will be archiving it > > in Nov. Here’s the link to the notice > > https://github.com/helm/charts/blob/master/README.md#deprecation-timeline > > > > It looks like that are quite a few charts for ASF projects such as Airflow, > > Hadoop, Spark, Solr (not exhaustive) that have yet to be adopted by anyone. > > It would make sense to re-home them into a single git in for example > > apache/charts. This would facilitate easier distribution of various ASF > > projects via a single helm repo, and setting up tests and CI integration > > needs only to be done once. > > > > Cheers, > > WJ > > > > - > > 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
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
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 > >
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
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
Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git
I've been thinking a lot and discussing the issues mentioned here (as in Apache Airflow we had this very case to solve. I would like to extend what Kamil wrote - and comment on what Apache Airflow uses and some of the recent discussions we had. I think we had very recently a lot of discussions about the Helm chart, licencing, releasing mechanisms so that might be a useful experience for everyone. TL;DR; I think it is a GREAT idea to have a single place from where all ASF charts will be hosted. That has a number of advantages and solves a number of pain points we experienced so far with the distribution mechanism of the Helm Charts and I think it's a great opportunity to plug a small "ambiguity" in the ASF release policy - coming from the way how Helm and Docker Images in general are a bit different than the "existing release mechanism". This is not a big ambiguity IMHO and the current rules of the release policy can be interpreted and applied to Helm Chart policies, but it would be simply great to make clear rules about both - images and charts as they will likely become a very important distribution and release mechanism in the near future (if not already did). Some ideas/proposals resulting from the discussions I raised: 1) I think having ASF "apache/chart" for all "officially released" helm charts is the best solution. This should not be a place where the helm charts are developed - but you should be able to get a released and tagged versions of those charts. Each project should have their own way of developing the chart (might be in mono-repo with other parts of the system or separate repo). For example in Airflow we are developing chart together with main Airflow code and we are using it during the CI to run tests - effectively testing "official image", "airflow code" and "airlfow chart" from the latest master together - so we chose to keep monorepo with all those. But for other projects, they might have "apache/project-chart" repo with only the chart. This should be project-based decision. 2) There are already tools (such as https://github.com/google/copybara) that allow to copy selectively parts of the repositories. And with Github Actions, we could very easily write an automation where each project could configure where their chart repository is, which folder, branch and tags are used and the common "ASF Chart" repo could easily pull-in such charts. This way releases marked as tags in the original projects would automatically land in the "ASF Chart" repo - also some validation might be put in place to make sure the pulled chart is "good to go" and some notifications might be in place if they are not. I am super-happy to help with such automation - I've done a lot of Github Actions work recently for Apache Airflow and helped Apache Beam as well - including developing a very useful https://github.com/marketplace/actions/cancel-workflow-runs action that cancels duplicate Github Actions Workflow and helps us to optimise our Job usage and CI feedback time by 30%. 3) Regarding the licencing, policies - I started recently a discussion about this very subject https://lists.apache.org/thread.html/rf2af2a95e7687fe94ede23fe9df388f784c8231a5968b109f677cbe8%40%3Cbuilds.apache.org%3E and there was no "definittive" or "clear" answers. There is no direct mentioning of Helm or Docker release mechanisms in the http://www.apache.org/legal/release-policy.html but IMHO we can interpret some of the statements there. I will put relevant parts from the policy with my interpretation: a) Docker Images are - rather clearly - binary convenience packages and we are free to provide them to the users as such - as long we also give users a way to recreate them as long as they have necessary platform and tools. So all the sources required to rebuild those images MUST be released as an "official source package" - following all the rules of ASF (voting, signing etc.). According to that - I think there is no need to vote on releasing the Docker Images as long as they are build the same sources that have been officially voted and released. > As a convenience to users that might not have the appropriate tools to build a compiled version of the source, binary/bytecode packages MAY be distributed alongside official Apache releases. In all such cases, the binary/bytecode package MUST have the same version number as the source release and MUST only add binary/bytecode files that are the result of compiling that version of the source code release and its dependencies. b) Helm Chart sources - they are sources not binary releases. So sources of the Helm Chart should be officially voted, signed and released. However the official release process should be the regular "release process" and can be made part of the source package in "downloads.apache.org". In case of Airflow's monorepo for example - we will just include helm chart sources next time when we release Airflow 1.10.13 and this will also be the "official" Helm Chart release. We
