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 [email protected] 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 [email protected] 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 <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/5957b403-8f01-45cc-8b1c-422c6841efc7n%40googlegroups.com.
