Hi everyone đź‘‹ I'm helping with the overall helm stable repo move to find the charts their new homes (see https://github.com/helm/charts/issues/21103 for overview status of each chart, and please help us keep those updated by linking to that issue).
In order to speed this up a bit for prometheus charts, per https://prometheus.io/community/ I joined Freenode IRC #prometheus-dev channel to help with any real time questions about this, and make immediate next steps. I've opened https://github.com/prometheus-community/community/issues/28 to create a new prometheus-community/helm-charts git repo, and added context there, including linking and summarizing relevant open questions on this email thread. Tl;dr, I think we should move all prometheus-related charts as-is to the new git repo with the initial priority to unblock the the stable charts deprecation. The longer-term goal can be working with prometheus developers and community within that repo to refactor and deprecate/rename as needed according to ongoing discussion about more appropriate architecture/naming. This solution allows incremental improvements without blocking the overall effort. Also see my comments <https://github.com/prometheus-operator/prometheus-operator/issues/3169#issuecomment-669343006> on the open question about prometheus-operator chart. Tl;dr: if the prometheus-operator org decides to accept it before we move the rest of the prometheus charts to prometheus-community/helm-charts, then great. Otherwise I believe we should include it with the others to begin, with the idea that we can always deprecate and move to the prometheus-operator org later if/when they accept it. Either way, this allows it to not be a blocker of the overall effort. PS, I think the linked prometheus-community/community issue above addresses most of the rest of the concerns in this mail thread, but one open comment above I didn't address there was CĂ©dric's note about git repo naming for forking purposes - the reason was simplicity and following what most of the community is doing. I agree it's annoying to rename repos when forking on GitHub, but this is why they let you do it during fork (contributors can rename to "prometheus-helm-charts" or whatever else you they wish when forking, just like helm repos by jagertracing, fluent, kong, jfrog, bitnami etc). But I agree 100% about your note on Helm automation tools including the GH Action wrappers! Let's join the conversation on that prometheus-community/community issue if there are any other open questions or concerns. Thanks! Scott On Tuesday, August 4, 2020 at 4:02:45 PM UTC-4 fr...@sumologic.com wrote: > Hi folks. Was a conclusion reached on this? I am a PM at Sumo Logic and > we use the Helm charts as part of our solution and was not sure if a > concensus had been reached. > > On Tuesday, June 30, 2020 at 2:27:03 PM UTC-6 husson....@gmail.com wrote: > >> Up, >> >> @Prometheus Developers for the vote, maybe you would like to do it in >> another topic ? >> >> @Stuart yeah for the option 3 it would make more sense to have in a >> dedicated organization. But the idea is there at least :) >> >> Le mar. 23 juin 2020 Ă 14:42, Stuart Clark <stuart...@jahingo.com> a >> Ă©crit : >> >>> On 2020-06-23 09:30, Augustin Husson wrote: >>> > @Mingchin Hsieh Sorry I didn't get your point. To enable the CI/CD >>> > with circle-ci, yes you need to have the admin right. Otherwise to see >>> > how the CI/CD is working you don't need any special right. >>> > @Cedric that's nice ! I didn't know about it. Thanks a lot :) >>> > >>> > I think here we need to have a vote, because I think now it just >>> > matters of what to do. >>> > >>> > To the @Prometheus Developers can you please vote on the following >>> > proposition ? >>> > >>> > 1. ONE HELM-CHART REPOSITORY PER ORGANIZATION >>> > * one repository PROMETHEUS-HELM-CHARTS will be created in the >>> > organization PROMETHEUS that will contain the helm chart of: >>> > * prometheus >>> > * alertManager >>> > * node-exporter >>> > * other helm chart relative to the repository contained in the >>> > current organization >>> > * one repository PROMETHEUS-HEM-CHARTS will be created in the >>> > organization PROMETHEUS-COMMUNITY that will contain the helm chart of: >>> > * jira-alerting >>> > * other helm chart relative to the repository contained in the >>> > current organization >>> > >>> > 2. ONE HELM CHART FOR EVERYTHING >>> > We will create a repository prometheus-helm-charts in >>> > prometheus-community that will contain everything. >>> > >>> > 3. ONE REPOSITORY PER HELM-CHARTS IN THE ORG PROMETHEUS-COMMUNITY >>> > * prometheus-community/prometheus-helm-chart >>> > * prometheus-community/node-exporter-helm-chart >>> > * prometheus-community/alert-manager-helm-chart >>> > * prometheus-community/jira-alert-helm-chart >>> > >>> > I hope I didn't forget any proposition and it's well summarize. Please >>> > reply if you think there is something missing. >>> > >>> > on my side I'm more in FAVOR OF THE PROPOSITION 1. >>> > >>> >>> If you went with a repo per chart, rather than option 3 it would >>> probably be nicer to have a new organisation specifically for helm >>> charts (prometheus-community-helm or something) >>> >>> -- >>> Stuart Clark >>> >> -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/5957b403-8f01-45cc-8b1c-422c6841efc7n%40googlegroups.com.
