Re: [prometheus-developers] Re: Helm charts home

[Scott Rigby]

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 

 
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  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 

Re: [prometheus-developers] Re: Helm charts home

[fr...@sumologic.com]

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  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/03caf3b1-50a7-4333-b4b6-0fc254bf719cn%40googlegroups.com.

Re: [prometheus-developers] Re: Helm charts home

[Augustin Husson]

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  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/CAOJizGe%3Dq2SoAU-r8XQn21Goszcf4LLumR3e9HKog1Ct40KVdg%40mail.gmail.com.

Re: [prometheus-developers] Re: Helm charts home

[Stuart Clark]

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/39f34146be8e3bcffe19687f88b865e8%40Jahingo.com.

Re: [prometheus-developers] Re: Helm charts home

[Mingchin Hsieh]

Hi Augustin,

No problem; just curious if prometheus-community reviewers / owners need
help.

Best,
Mingchin

On Tue, Jun 23, 2020 at 4:30 PM 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.*
>
> Kinds regards,
>
> Le lun. 22 juin 2020 à 16:51, Mingchin Hsieh  a
> écrit :
>
>> BTW, for maintainers of prometheus-community, do you guys need to be
>> granted as one of owners in prometheus-something chart in order to see or
>> have a taste of the current helm stable chart CICD process?
>>
>> If so, please let me know, or ping any helm members. Thanks.
>>
>> On Mon, Jun 22, 2020 at 10:40 PM Cédric De Saint Martin <
>> cdesaintmar...@wiremind.io> wrote:
>>
>>> Hello,
>>>
>>> prometheus-something chart maintainer here. ;)
>>>
>>> Actually, it is quite simple to use
>>> https://github.com/helm/chart-testing (and if you're going to use
>>> GitHub Actions, https://github.com/helm/chart-testing-action) and/or
>>> https://github.com/helm/chart-releaser, which automates all the testing
>>> / release procedures (and, of course, only process the one being changed).
>>> I can help to setup this if needed.
>>>
>>> Note that if you're going to use a single repo, please name it
>>> prometheus-helm-charts instead of just helm-charts. Forking this repo
>>> results in a wierd state (I think I have fork of several "helm-charts"
>>> repository on my GitHub, which results being named helm-charts-1,
>>> helm-charts-2, etc).
>>>
>>>
>>> Le samedi 20 juin 2020 10:40:47 UTC+2, Augustin Husson a écrit :

 Hello,

 Well having a single repo for each chart would create so much
 repositories and IMHO just imagine to create for each of them the CI/CD
 even if it's the same each time, is to exausting. ( Yeah I'm a bit lazy)

 Moreover if you have to change one CI/CD for whatever reason you will
 have to change it in all of them to keep the same.

 Then it's quite fine to have a single repo of all helm-charts. We can
 even imagine to create a bit clever scrip that will only run the test for
 the charts that changed. That's not super rocket science I think.

 And perhaps it makes sense actually to split the helm-charts into 2
 repo. One could go to prometheus and will have the helm chart owned by
 prometheus. Then another one that will go to prometheus-community that will
 contain the others (like the jira-alerts).

 This split is just to provide to the helm chart of
 prometheus/alertManager/node-exporter a better visibility and a sort of tag
 "official helm chart of prometheus"

 Kinds regards

 Le ven. 19 juin 2020 à 20:14, Mingchin Hsieh  a
 écrit :

> Hi André,
>
> I would take back what I said. I originally intended to not mess-up
> repos under prometheus-community and might think too much on current CI 
> e2e
> testing stucking issues.
>
> Best,
> Mingchin
>
> On Sat, Jun 20, 2020 at 1:50 AM André Bauer  wrote:
>
>> Why would you want to add "helm-chart" in the name of the chart and
>> have multiple repos?
>>
>> Imho it would be:
>>
>> helm-charts/prometheus
>> helm-charts/alertmanager
>> helm-charts/...
>>
>> and so on. So being "helm-charts" the repos main directory and the
>> charts inside of it.
>> Adding "helm-chart" to the name would also waste 

Re: [prometheus-developers] Re: Helm charts home

[Augustin Husson]

@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.*

Kinds regards,

Le lun. 22 juin 2020 à 16:51, Mingchin Hsieh  a écrit :

> BTW, for maintainers of prometheus-community, do you guys need to be
> granted as one of owners in prometheus-something chart in order to see or
> have a taste of the current helm stable chart CICD process?
>
> If so, please let me know, or ping any helm members. Thanks.
>
> On Mon, Jun 22, 2020 at 10:40 PM Cédric De Saint Martin <
> cdesaintmar...@wiremind.io> wrote:
>
>> Hello,
>>
>> prometheus-something chart maintainer here. ;)
>>
>> Actually, it is quite simple to use https://github.com/helm/chart-testing
>> (and if you're going to use GitHub Actions,
>> https://github.com/helm/chart-testing-action) and/or
>> https://github.com/helm/chart-releaser, which automates all the testing
>> / release procedures (and, of course, only process the one being changed).
>> I can help to setup this if needed.
>>
>> Note that if you're going to use a single repo, please name it
>> prometheus-helm-charts instead of just helm-charts. Forking this repo
>> results in a wierd state (I think I have fork of several "helm-charts"
>> repository on my GitHub, which results being named helm-charts-1,
>> helm-charts-2, etc).
>>
>>
>> Le samedi 20 juin 2020 10:40:47 UTC+2, Augustin Husson a écrit :
>>>
>>> Hello,
>>>
>>> Well having a single repo for each chart would create so much
>>> repositories and IMHO just imagine to create for each of them the CI/CD
>>> even if it's the same each time, is to exausting. ( Yeah I'm a bit lazy)
>>>
>>> Moreover if you have to change one CI/CD for whatever reason you will
>>> have to change it in all of them to keep the same.
>>>
>>> Then it's quite fine to have a single repo of all helm-charts. We can
>>> even imagine to create a bit clever scrip that will only run the test for
>>> the charts that changed. That's not super rocket science I think.
>>>
>>> And perhaps it makes sense actually to split the helm-charts into 2
>>> repo. One could go to prometheus and will have the helm chart owned by
>>> prometheus. Then another one that will go to prometheus-community that will
>>> contain the others (like the jira-alerts).
>>>
>>> This split is just to provide to the helm chart of
>>> prometheus/alertManager/node-exporter a better visibility and a sort of tag
>>> "official helm chart of prometheus"
>>>
>>> Kinds regards
>>>
>>> Le ven. 19 juin 2020 à 20:14, Mingchin Hsieh  a
>>> écrit :
>>>
 Hi André,

 I would take back what I said. I originally intended to not mess-up
 repos under prometheus-community and might think too much on current CI e2e
 testing stucking issues.

 Best,
 Mingchin

 On Sat, Jun 20, 2020 at 1:50 AM André Bauer  wrote:

> Why would you want to add "helm-chart" in the name of the chart and
> have multiple repos?
>
> Imho it would be:
>
> helm-charts/prometheus
> helm-charts/alertmanager
> helm-charts/...
>
> and so on. So being "helm-charts" the repos main directory and the
> charts inside of it.
> Adding "helm-chart" to the name would also waste chars in helms
> limited release name lenght.
>
> Maintenance of single repos for every chart would also be total
> overkill.
> Imagine alone changes in the CI would be done multiple times.
>
>
>
> zanh...@gmail.com schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2:
>
>> Hi Stuart,
>>

Re: [prometheus-developers] Re: Helm charts home

[Mingchin Hsieh]

BTW, for maintainers of prometheus-community, do you guys need to be
granted as one of owners in prometheus-something chart in order to see or
have a taste of the current helm stable chart CICD process?

If so, please let me know, or ping any helm members. Thanks.

On Mon, Jun 22, 2020 at 10:40 PM Cédric De Saint Martin <
cdesaintmar...@wiremind.io> wrote:

> Hello,
>
> prometheus-something chart maintainer here. ;)
>
> Actually, it is quite simple to use https://github.com/helm/chart-testing
> (and if you're going to use GitHub Actions,
> https://github.com/helm/chart-testing-action) and/or
> https://github.com/helm/chart-releaser, which automates all the testing /
> release procedures (and, of course, only process the one being changed). I
> can help to setup this if needed.
>
> Note that if you're going to use a single repo, please name it
> prometheus-helm-charts instead of just helm-charts. Forking this repo
> results in a wierd state (I think I have fork of several "helm-charts"
> repository on my GitHub, which results being named helm-charts-1,
> helm-charts-2, etc).
>
>
> Le samedi 20 juin 2020 10:40:47 UTC+2, Augustin Husson a écrit :
>>
>> Hello,
>>
>> Well having a single repo for each chart would create so much
>> repositories and IMHO just imagine to create for each of them the CI/CD
>> even if it's the same each time, is to exausting. ( Yeah I'm a bit lazy)
>>
>> Moreover if you have to change one CI/CD for whatever reason you will
>> have to change it in all of them to keep the same.
>>
>> Then it's quite fine to have a single repo of all helm-charts. We can
>> even imagine to create a bit clever scrip that will only run the test for
>> the charts that changed. That's not super rocket science I think.
>>
>> And perhaps it makes sense actually to split the helm-charts into 2 repo.
>> One could go to prometheus and will have the helm chart owned by
>> prometheus. Then another one that will go to prometheus-community that will
>> contain the others (like the jira-alerts).
>>
>> This split is just to provide to the helm chart of
>> prometheus/alertManager/node-exporter a better visibility and a sort of tag
>> "official helm chart of prometheus"
>>
>> Kinds regards
>>
>> Le ven. 19 juin 2020 à 20:14, Mingchin Hsieh  a
>> écrit :
>>
>>> Hi André,
>>>
>>> I would take back what I said. I originally intended to not mess-up
>>> repos under prometheus-community and might think too much on current CI e2e
>>> testing stucking issues.
>>>
>>> Best,
>>> Mingchin
>>>
>>> On Sat, Jun 20, 2020 at 1:50 AM André Bauer  wrote:
>>>
 Why would you want to add "helm-chart" in the name of the chart and
 have multiple repos?

 Imho it would be:

 helm-charts/prometheus
 helm-charts/alertmanager
 helm-charts/...

 and so on. So being "helm-charts" the repos main directory and the
 charts inside of it.
 Adding "helm-chart" to the name would also waste chars in helms limited
 release name lenght.

 Maintenance of single repos for every chart would also be total
 overkill.
 Imagine alone changes in the CI would be done multiple times.



 zanh...@gmail.com schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2:

> Hi Stuart,
>
> No. My ideal expectation would be different repos, unless cost and /
> or maintenance is too high.
>
> Best,
> Mingchin
>
> On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark 
> wrote:
>
>> On 2020-06-19 15:09, Mingchin Hsieh wrote:
>> > Hi,
>> >
>> > I sort of agree with Stuart's idea; only a little tweak: adding
>> > helm-chart as prefix or suffix. For example,
>> >
>> > Prefix approach -
>> > helm-chart-prometheus-adapter
>> > helm-chart-prometheus-blackbox-exporter
>> > helm-chart-prometheus-cloudwatch-exporter
>> > helm-chart-prometheus-consul-exporter
>> > helm-chart-prometheus-couchdb-exporter
>> > helm-chart-prometheus-mongodb-exporter
>> > helm-chart-prometheus-mysql-exporter
>> > helm-chart-prometheus-nats-exporter
>> > helm-chart-prometheus-node-exporter
>> > helm-chart-prometheus-operator
>> > helm-chart-prometheus-postgres-exporter
>> > helm-chart-prometheus-pushgateway
>> > helm-chart-prometheus-rabbitmq-exporter
>> > helm-chart-prometheus-redis-exporter
>> > helm-chart-prometheus-snmp-exporter
>> > helm-chart-prometheus-to-sd
>> > helm-chart-prometheus
>> >
>> > Suffix approach -
>> > prometheus-adapter-helm-chart
>> > prometheus-blackbox-exporter-helm-chart
>> > prometheus-cloudwatch-exporter-helm-chart
>> > prometheus-consul-exporter-helm-chart
>> > prometheus-couchdb-exporter-helm-chart
>> > prometheus-mongodb-exporter-helm-chart
>> > 

Re: [prometheus-developers] Re: Helm charts home

[Cédric De Saint Martin]

Hello,

prometheus-something chart maintainer here. ;)

Actually, it is quite simple to use https://github.com/helm/chart-testing 
(and if you're going to use GitHub Actions, 
https://github.com/helm/chart-testing-action) and/or 
https://github.com/helm/chart-releaser, which automates all the testing / 
release procedures (and, of course, only process the one being changed). I 
can help to setup this if needed.

Note that if you're going to use a single repo, please name it 
prometheus-helm-charts instead of just helm-charts. Forking this repo 
results in a wierd state (I think I have fork of several "helm-charts" 
repository on my GitHub, which results being named helm-charts-1, 
helm-charts-2, etc).


Le samedi 20 juin 2020 10:40:47 UTC+2, Augustin Husson a écrit :
>
> Hello,
>
> Well having a single repo for each chart would create so much repositories 
> and IMHO just imagine to create for each of them the CI/CD even if it's the 
> same each time, is to exausting. ( Yeah I'm a bit lazy)
>
> Moreover if you have to change one CI/CD for whatever reason you will have 
> to change it in all of them to keep the same.
>
> Then it's quite fine to have a single repo of all helm-charts. We can even 
> imagine to create a bit clever scrip that will only run the test for the 
> charts that changed. That's not super rocket science I think.
>
> And perhaps it makes sense actually to split the helm-charts into 2 repo. 
> One could go to prometheus and will have the helm chart owned by 
> prometheus. Then another one that will go to prometheus-community that will 
> contain the others (like the jira-alerts).
>
> This split is just to provide to the helm chart of 
> prometheus/alertManager/node-exporter a better visibility and a sort of tag 
> "official helm chart of prometheus"
>
> Kinds regards
>
> Le ven. 19 juin 2020 à 20:14, Mingchin Hsieh  > a écrit :
>
>> Hi André,
>>
>> I would take back what I said. I originally intended to not mess-up repos 
>> under prometheus-community and might think too much on current CI e2e 
>> testing stucking issues. 
>>
>> Best,
>> Mingchin
>>
>> On Sat, Jun 20, 2020 at 1:50 AM André Bauer > > wrote:
>>
>>> Why would you want to add "helm-chart" in the name of the chart and have 
>>> multiple repos?
>>>
>>> Imho it would be:
>>>
>>> helm-charts/prometheus
>>> helm-charts/alertmanager
>>> helm-charts/...
>>>
>>> and so on. So being "helm-charts" the repos main directory and the 
>>> charts inside of it.
>>> Adding "helm-chart" to the name would also waste chars in helms limited 
>>> release name lenght.
>>>
>>> Maintenance of single repos for every chart would also be total 
>>> overkill. 
>>> Imagine alone changes in the CI would be done multiple times.
>>>
>>>
>>>
>>> zanh...@gmail.com schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2:
>>>
 Hi Stuart,

 No. My ideal expectation would be different repos, unless cost and / or 
 maintenance is too high. 

 Best,
 Mingchin

 On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark  
 wrote:

> On 2020-06-19 15:09, Mingchin Hsieh wrote:
> > Hi,
> > 
> > I sort of agree with Stuart's idea; only a little tweak: adding
> > helm-chart as prefix or suffix. For example,
> > 
> > Prefix approach -
> > helm-chart-prometheus-adapter
> > helm-chart-prometheus-blackbox-exporter
> > helm-chart-prometheus-cloudwatch-exporter
> > helm-chart-prometheus-consul-exporter
> > helm-chart-prometheus-couchdb-exporter
> > helm-chart-prometheus-mongodb-exporter
> > helm-chart-prometheus-mysql-exporter
> > helm-chart-prometheus-nats-exporter
> > helm-chart-prometheus-node-exporter
> > helm-chart-prometheus-operator
> > helm-chart-prometheus-postgres-exporter
> > helm-chart-prometheus-pushgateway
> > helm-chart-prometheus-rabbitmq-exporter
> > helm-chart-prometheus-redis-exporter
> > helm-chart-prometheus-snmp-exporter
> > helm-chart-prometheus-to-sd
> > helm-chart-prometheus
> > 
> > Suffix approach -
> > prometheus-adapter-helm-chart
> > prometheus-blackbox-exporter-helm-chart
> > prometheus-cloudwatch-exporter-helm-chart
> > prometheus-consul-exporter-helm-chart
> > prometheus-couchdb-exporter-helm-chart
> > prometheus-mongodb-exporter-helm-chart
> > prometheus-mysql-exporter-helm-chart
> > prometheus-nats-exporter-helm-chart
> > prometheus-node-exporter-helm-chart
> > prometheus-operator-helm-chart
> > prometheus-postgres-exporter-helm-chart
> > prometheus-pushgateway-helm-chart
> > prometheus-rabbitmq-exporter-helm-chart
> > prometheus-redis-exporter-helm-chart
> > prometheus-snmp-exporter-helm-chart
> >   

Re: [prometheus-developers] Re: Helm charts home

[Augustin Husson]

Hello,

Well having a single repo for each chart would create so much repositories
and IMHO just imagine to create for each of them the CI/CD even if it's the
same each time, is to exausting. ( Yeah I'm a bit lazy)

Moreover if you have to change one CI/CD for whatever reason you will have
to change it in all of them to keep the same.

Then it's quite fine to have a single repo of all helm-charts. We can even
imagine to create a bit clever scrip that will only run the test for the
charts that changed. That's not super rocket science I think.

And perhaps it makes sense actually to split the helm-charts into 2 repo.
One could go to prometheus and will have the helm chart owned by
prometheus. Then another one that will go to prometheus-community that will
contain the others (like the jira-alerts).

This split is just to provide to the helm chart of
prometheus/alertManager/node-exporter a better visibility and a sort of tag
"official helm chart of prometheus"

Kinds regards

Le ven. 19 juin 2020 à 20:14, Mingchin Hsieh  a écrit :

> Hi André,
>
> I would take back what I said. I originally intended to not mess-up repos
> under prometheus-community and might think too much on current CI e2e
> testing stucking issues.
>
> Best,
> Mingchin
>
> On Sat, Jun 20, 2020 at 1:50 AM André Bauer  wrote:
>
>> Why would you want to add "helm-chart" in the name of the chart and have
>> multiple repos?
>>
>> Imho it would be:
>>
>> helm-charts/prometheus
>> helm-charts/alertmanager
>> helm-charts/...
>>
>> and so on. So being "helm-charts" the repos main directory and the charts
>> inside of it.
>> Adding "helm-chart" to the name would also waste chars in helms limited
>> release name lenght.
>>
>> Maintenance of single repos for every chart would also be total overkill.
>> Imagine alone changes in the CI would be done multiple times.
>>
>>
>>
>> zanh...@gmail.com schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2:
>>
>>> Hi Stuart,
>>>
>>> No. My ideal expectation would be different repos, unless cost and / or
>>> maintenance is too high.
>>>
>>> Best,
>>> Mingchin
>>>
>>> On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark 
>>> wrote:
>>>
 On 2020-06-19 15:09, Mingchin Hsieh wrote:
 > Hi,
 >
 > I sort of agree with Stuart's idea; only a little tweak: adding
 > helm-chart as prefix or suffix. For example,
 >
 > Prefix approach -
 > helm-chart-prometheus-adapter
 > helm-chart-prometheus-blackbox-exporter
 > helm-chart-prometheus-cloudwatch-exporter
 > helm-chart-prometheus-consul-exporter
 > helm-chart-prometheus-couchdb-exporter
 > helm-chart-prometheus-mongodb-exporter
 > helm-chart-prometheus-mysql-exporter
 > helm-chart-prometheus-nats-exporter
 > helm-chart-prometheus-node-exporter
 > helm-chart-prometheus-operator
 > helm-chart-prometheus-postgres-exporter
 > helm-chart-prometheus-pushgateway
 > helm-chart-prometheus-rabbitmq-exporter
 > helm-chart-prometheus-redis-exporter
 > helm-chart-prometheus-snmp-exporter
 > helm-chart-prometheus-to-sd
 > helm-chart-prometheus
 >
 > Suffix approach -
 > prometheus-adapter-helm-chart
 > prometheus-blackbox-exporter-helm-chart
 > prometheus-cloudwatch-exporter-helm-chart
 > prometheus-consul-exporter-helm-chart
 > prometheus-couchdb-exporter-helm-chart
 > prometheus-mongodb-exporter-helm-chart
 > prometheus-mysql-exporter-helm-chart
 > prometheus-nats-exporter-helm-chart
 > prometheus-node-exporter-helm-chart
 > prometheus-operator-helm-chart
 > prometheus-postgres-exporter-helm-chart
 > prometheus-pushgateway-helm-chart
 > prometheus-rabbitmq-exporter-helm-chart
 > prometheus-redis-exporter-helm-chart
 > prometheus-snmp-exporter-helm-chart
 > prometheus-to-sd-helm-chart
 > prometheus-helm-chart
 >
 > This is due to there are some existing repos in prometheus-community
 > that focus on each component implementation level (e.g. docker image
 > or stand-alone service). Mixing together might be harder to put on
 > hub.helm.sh [1]. But, the owners of prometheus-community hold their
 > right for the final decision.
 >
 > BTW, would any prometheus-community owners / members explain the
 > current testing infrastructure? Currently helm chart testing infra is
 > based on Google Bazel + CircleCI. There's some limitation over there,
 > e.g. the chart owners / approvers debug the testing infra is hard. I
 > think all the current prometheus related helm chart owners would like
 > to know how hard would be for migration / automation.
 >
 > Best,
 > Mingchin
 >
 > On Fri, Jun 19, 2020 at 8:55 

Re: [prometheus-developers] Re: Helm charts home

[Mingchin Hsieh]

Hi André,

I would take back what I said. I originally intended to not mess-up repos
under prometheus-community and might think too much on current CI e2e
testing stucking issues.

Best,
Mingchin

On Sat, Jun 20, 2020 at 1:50 AM André Bauer  wrote:

> Why would you want to add "helm-chart" in the name of the chart and have
> multiple repos?
>
> Imho it would be:
>
> helm-charts/prometheus
> helm-charts/alertmanager
> helm-charts/...
>
> and so on. So being "helm-charts" the repos main directory and the charts
> inside of it.
> Adding "helm-chart" to the name would also waste chars in helms limited
> release name lenght.
>
> Maintenance of single repos for every chart would also be total overkill.
> Imagine alone changes in the CI would be done multiple times.
>
>
>
> zanh...@gmail.com schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2:
>
>> Hi Stuart,
>>
>> No. My ideal expectation would be different repos, unless cost and / or
>> maintenance is too high.
>>
>> Best,
>> Mingchin
>>
>> On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark 
>> wrote:
>>
>>> On 2020-06-19 15:09, Mingchin Hsieh wrote:
>>> > Hi,
>>> >
>>> > I sort of agree with Stuart's idea; only a little tweak: adding
>>> > helm-chart as prefix or suffix. For example,
>>> >
>>> > Prefix approach -
>>> > helm-chart-prometheus-adapter
>>> > helm-chart-prometheus-blackbox-exporter
>>> > helm-chart-prometheus-cloudwatch-exporter
>>> > helm-chart-prometheus-consul-exporter
>>> > helm-chart-prometheus-couchdb-exporter
>>> > helm-chart-prometheus-mongodb-exporter
>>> > helm-chart-prometheus-mysql-exporter
>>> > helm-chart-prometheus-nats-exporter
>>> > helm-chart-prometheus-node-exporter
>>> > helm-chart-prometheus-operator
>>> > helm-chart-prometheus-postgres-exporter
>>> > helm-chart-prometheus-pushgateway
>>> > helm-chart-prometheus-rabbitmq-exporter
>>> > helm-chart-prometheus-redis-exporter
>>> > helm-chart-prometheus-snmp-exporter
>>> > helm-chart-prometheus-to-sd
>>> > helm-chart-prometheus
>>> >
>>> > Suffix approach -
>>> > prometheus-adapter-helm-chart
>>> > prometheus-blackbox-exporter-helm-chart
>>> > prometheus-cloudwatch-exporter-helm-chart
>>> > prometheus-consul-exporter-helm-chart
>>> > prometheus-couchdb-exporter-helm-chart
>>> > prometheus-mongodb-exporter-helm-chart
>>> > prometheus-mysql-exporter-helm-chart
>>> > prometheus-nats-exporter-helm-chart
>>> > prometheus-node-exporter-helm-chart
>>> > prometheus-operator-helm-chart
>>> > prometheus-postgres-exporter-helm-chart
>>> > prometheus-pushgateway-helm-chart
>>> > prometheus-rabbitmq-exporter-helm-chart
>>> > prometheus-redis-exporter-helm-chart
>>> > prometheus-snmp-exporter-helm-chart
>>> > prometheus-to-sd-helm-chart
>>> > prometheus-helm-chart
>>> >
>>> > This is due to there are some existing repos in prometheus-community
>>> > that focus on each component implementation level (e.g. docker image
>>> > or stand-alone service). Mixing together might be harder to put on
>>> > hub.helm.sh [1]. But, the owners of prometheus-community hold their
>>> > right for the final decision.
>>> >
>>> > BTW, would any prometheus-community owners / members explain the
>>> > current testing infrastructure? Currently helm chart testing infra is
>>> > based on Google Bazel + CircleCI. There's some limitation over there,
>>> > e.g. the chart owners / approvers debug the testing infra is hard. I
>>> > think all the current prometheus related helm chart owners would like
>>> > to know how hard would be for migration / automation.
>>> >
>>> > Best,
>>> > Mingchin
>>> >
>>> > On Fri, Jun 19, 2020 at 8:55 PM Stuart Clark
>>> >  wrote:
>>> >
>>> >> On 2020-06-19 13:30, André Bauer wrote:
>>> >>> Hey guys,
>>> >>>
>>> >>> great to see there is already some effort to move the chart out of
>>> >> the
>>> >>> stable repo :)
>>> >>>
>>> >>> As i understand that "prometheus" is not the perfect fit for the
>>> >> chart
>>> >>> name, as it also installs other components from the prometheus eco
>>> >>> system, i'm also not the biggest fan of umbrella charts.
>>> >>> From our experience at kiwigrid this can lead to updating issues.
>>> >>> For example you'd need to update proemtheus server but because of
>>> >> the
>>> >>> umbrella it could alreadya fail and exit in the alertmanager
>>> >> update
>>> >>> step.
>>> >>> Therefore we switched to single chart installs now as you're able
>>> >> to
>>> >>> update single components, without the need to run the update for
>>> >> all
>>> >>> charts under the umbrella, which is much more error resistent from
>>> >> our
>>> >>> experience.
>>> >>>
>>> >>> Nevertheless an umbrella chart might be good starting point for
>>> >>> testing Prometheus with all of its available components.
>>> >>>
>>> >>> Where i see 

Re: [prometheus-developers] Re: Helm charts home

[André Bauer]

Why would you want to add "helm-chart" in the name of the chart and have 
multiple repos?

Imho it would be:

helm-charts/prometheus
helm-charts/alertmanager
helm-charts/...

and so on. So being "helm-charts" the repos main directory and the charts 
inside of it.
Adding "helm-chart" to the name would also waste chars in helms limited 
release name lenght.

Maintenance of single repos for every chart would also be total overkill. 
Imagine alone changes in the CI would be done multiple times.



zanh...@gmail.com schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2:

> Hi Stuart,
>
> No. My ideal expectation would be different repos, unless cost and / or 
> maintenance is too high. 
>
> Best,
> Mingchin
>
> On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark  
> wrote:
>
>> On 2020-06-19 15:09, Mingchin Hsieh wrote:
>> > Hi,
>> > 
>> > I sort of agree with Stuart's idea; only a little tweak: adding
>> > helm-chart as prefix or suffix. For example,
>> > 
>> > Prefix approach -
>> > helm-chart-prometheus-adapter
>> > helm-chart-prometheus-blackbox-exporter
>> > helm-chart-prometheus-cloudwatch-exporter
>> > helm-chart-prometheus-consul-exporter
>> > helm-chart-prometheus-couchdb-exporter
>> > helm-chart-prometheus-mongodb-exporter
>> > helm-chart-prometheus-mysql-exporter
>> > helm-chart-prometheus-nats-exporter
>> > helm-chart-prometheus-node-exporter
>> > helm-chart-prometheus-operator
>> > helm-chart-prometheus-postgres-exporter
>> > helm-chart-prometheus-pushgateway
>> > helm-chart-prometheus-rabbitmq-exporter
>> > helm-chart-prometheus-redis-exporter
>> > helm-chart-prometheus-snmp-exporter
>> > helm-chart-prometheus-to-sd
>> > helm-chart-prometheus
>> > 
>> > Suffix approach -
>> > prometheus-adapter-helm-chart
>> > prometheus-blackbox-exporter-helm-chart
>> > prometheus-cloudwatch-exporter-helm-chart
>> > prometheus-consul-exporter-helm-chart
>> > prometheus-couchdb-exporter-helm-chart
>> > prometheus-mongodb-exporter-helm-chart
>> > prometheus-mysql-exporter-helm-chart
>> > prometheus-nats-exporter-helm-chart
>> > prometheus-node-exporter-helm-chart
>> > prometheus-operator-helm-chart
>> > prometheus-postgres-exporter-helm-chart
>> > prometheus-pushgateway-helm-chart
>> > prometheus-rabbitmq-exporter-helm-chart
>> > prometheus-redis-exporter-helm-chart
>> > prometheus-snmp-exporter-helm-chart
>> > prometheus-to-sd-helm-chart
>> > prometheus-helm-chart
>> > 
>> > This is due to there are some existing repos in prometheus-community
>> > that focus on each component implementation level (e.g. docker image
>> > or stand-alone service). Mixing together might be harder to put on
>> > hub.helm.sh [1]. But, the owners of prometheus-community hold their
>> > right for the final decision.
>> > 
>> > BTW, would any prometheus-community owners / members explain the
>> > current testing infrastructure? Currently helm chart testing infra is
>> > based on Google Bazel + CircleCI. There's some limitation over there,
>> > e.g. the chart owners / approvers debug the testing infra is hard. I
>> > think all the current prometheus related helm chart owners would like
>> > to know how hard would be for migration / automation.
>> > 
>> > Best,
>> > Mingchin
>> > 
>> > On Fri, Jun 19, 2020 at 8:55 PM Stuart Clark
>> >  wrote:
>> > 
>> >> On 2020-06-19 13:30, André Bauer wrote:
>> >>> Hey guys,
>> >>> 
>> >>> great to see there is already some effort to move the chart out of
>> >> the
>> >>> stable repo :)
>> >>> 
>> >>> As i understand that "prometheus" is not the perfect fit for the
>> >> chart
>> >>> name, as it also installs other components from the prometheus eco
>> >>> system, i'm also not the biggest fan of umbrella charts.
>> >>> From our experience at kiwigrid this can lead to updating issues.
>> >>> For example you'd need to update proemtheus server but because of
>> >> the
>> >>> umbrella it could alreadya fail and exit in the alertmanager
>> >> update
>> >>> step.
>> >>> Therefore we switched to single chart installs now as you're able
>> >> to
>> >>> update single components, without the need to run the update for
>> >> all
>> >>> charts under the umbrella, which is much more error resistent from
>> >> our
>> >>> experience.
>> >>> 
>> >>> Nevertheless an umbrella chart might be good starting point for
>> >>> testing Prometheus with all of its available components.
>> >>> 
>> >>> Where i see problems is to deprecate the chart in stable and
>> >> change
>> >>> the way the chart works in the new repo.
>> >>> Maybe such changes should be done in an earlier step in the stable
>> >>> chart repo?
>> >>> At least doumentation of the upgrade path should be clear and
>> >>> possible, without the need to have manual steps like pvc backup /
>> >>> restore because 

Re: [prometheus-developers] Re: Helm charts home

[Mingchin Hsieh]

Hi Stuart,

No. My ideal expectation would be different repos, unless cost and / or
maintenance is too high.

Best,
Mingchin

On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark 
wrote:

> On 2020-06-19 15:09, Mingchin Hsieh wrote:
> > Hi,
> >
> > I sort of agree with Stuart's idea; only a little tweak: adding
> > helm-chart as prefix or suffix. For example,
> >
> > Prefix approach -
> > helm-chart-prometheus-adapter
> > helm-chart-prometheus-blackbox-exporter
> > helm-chart-prometheus-cloudwatch-exporter
> > helm-chart-prometheus-consul-exporter
> > helm-chart-prometheus-couchdb-exporter
> > helm-chart-prometheus-mongodb-exporter
> > helm-chart-prometheus-mysql-exporter
> > helm-chart-prometheus-nats-exporter
> > helm-chart-prometheus-node-exporter
> > helm-chart-prometheus-operator
> > helm-chart-prometheus-postgres-exporter
> > helm-chart-prometheus-pushgateway
> > helm-chart-prometheus-rabbitmq-exporter
> > helm-chart-prometheus-redis-exporter
> > helm-chart-prometheus-snmp-exporter
> > helm-chart-prometheus-to-sd
> > helm-chart-prometheus
> >
> > Suffix approach -
> > prometheus-adapter-helm-chart
> > prometheus-blackbox-exporter-helm-chart
> > prometheus-cloudwatch-exporter-helm-chart
> > prometheus-consul-exporter-helm-chart
> > prometheus-couchdb-exporter-helm-chart
> > prometheus-mongodb-exporter-helm-chart
> > prometheus-mysql-exporter-helm-chart
> > prometheus-nats-exporter-helm-chart
> > prometheus-node-exporter-helm-chart
> > prometheus-operator-helm-chart
> > prometheus-postgres-exporter-helm-chart
> > prometheus-pushgateway-helm-chart
> > prometheus-rabbitmq-exporter-helm-chart
> > prometheus-redis-exporter-helm-chart
> > prometheus-snmp-exporter-helm-chart
> > prometheus-to-sd-helm-chart
> > prometheus-helm-chart
> >
> > This is due to there are some existing repos in prometheus-community
> > that focus on each component implementation level (e.g. docker image
> > or stand-alone service). Mixing together might be harder to put on
> > hub.helm.sh [1]. But, the owners of prometheus-community hold their
> > right for the final decision.
> >
> > BTW, would any prometheus-community owners / members explain the
> > current testing infrastructure? Currently helm chart testing infra is
> > based on Google Bazel + CircleCI. There's some limitation over there,
> > e.g. the chart owners / approvers debug the testing infra is hard. I
> > think all the current prometheus related helm chart owners would like
> > to know how hard would be for migration / automation.
> >
> > Best,
> > Mingchin
> >
> > On Fri, Jun 19, 2020 at 8:55 PM Stuart Clark
> >  wrote:
> >
> >> On 2020-06-19 13:30, André Bauer wrote:
> >>> Hey guys,
> >>>
> >>> great to see there is already some effort to move the chart out of
> >> the
> >>> stable repo :)
> >>>
> >>> As i understand that "prometheus" is not the perfect fit for the
> >> chart
> >>> name, as it also installs other components from the prometheus eco
> >>> system, i'm also not the biggest fan of umbrella charts.
> >>> From our experience at kiwigrid this can lead to updating issues.
> >>> For example you'd need to update proemtheus server but because of
> >> the
> >>> umbrella it could alreadya fail and exit in the alertmanager
> >> update
> >>> step.
> >>> Therefore we switched to single chart installs now as you're able
> >> to
> >>> update single components, without the need to run the update for
> >> all
> >>> charts under the umbrella, which is much more error resistent from
> >> our
> >>> experience.
> >>>
> >>> Nevertheless an umbrella chart might be good starting point for
> >>> testing Prometheus with all of its available components.
> >>>
> >>> Where i see problems is to deprecate the chart in stable and
> >> change
> >>> the way the chart works in the new repo.
> >>> Maybe such changes should be done in an earlier step in the stable
> >>> chart repo?
> >>> At least doumentation of the upgrade path should be clear and
> >>> possible, without the need to have manual steps like pvc backup /
> >>> restore because the name of the pvc changed.
> >>>
> >>
> >> There are a number of existing charts in the stable repo, which are
> >> mostly for installing indivitual pieces:
> >>
> >> prometheus-adapter
> >> prometheus-blackbox-exporter
> >> prometheus-cloudwatch-exporter
> >> prometheus-consul-exporter
> >> prometheus-couchdb-exporter
> >> prometheus-mongodb-exporter
> >> prometheus-mysql-exporter
> >> prometheus-nats-exporter
> >> prometheus-node-exporter
> >> prometheus-operator
> >> prometheus-postgres-exporter
> >> prometheus-pushgateway
> >> prometheus-rabbitmq-exporter
> >> prometheus-redis-exporter
> >> prometheus-snmp-exporter
> >> prometheus-to-sd
> >> prometheus
> >>
> >> I'd suggest as a first 

Re: [prometheus-developers] Re: Helm charts home

[Stuart Clark]

On 2020-06-19 15:09, Mingchin Hsieh wrote:

Hi,

I sort of agree with Stuart's idea; only a little tweak: adding
helm-chart as prefix or suffix. For example,

Prefix approach -
helm-chart-prometheus-adapter
helm-chart-prometheus-blackbox-exporter
helm-chart-prometheus-cloudwatch-exporter
helm-chart-prometheus-consul-exporter
helm-chart-prometheus-couchdb-exporter
helm-chart-prometheus-mongodb-exporter
helm-chart-prometheus-mysql-exporter
helm-chart-prometheus-nats-exporter
helm-chart-prometheus-node-exporter
helm-chart-prometheus-operator
helm-chart-prometheus-postgres-exporter
helm-chart-prometheus-pushgateway
helm-chart-prometheus-rabbitmq-exporter
helm-chart-prometheus-redis-exporter
helm-chart-prometheus-snmp-exporter
helm-chart-prometheus-to-sd
helm-chart-prometheus

Suffix approach -
prometheus-adapter-helm-chart
prometheus-blackbox-exporter-helm-chart
prometheus-cloudwatch-exporter-helm-chart
prometheus-consul-exporter-helm-chart
prometheus-couchdb-exporter-helm-chart
prometheus-mongodb-exporter-helm-chart
prometheus-mysql-exporter-helm-chart
prometheus-nats-exporter-helm-chart
prometheus-node-exporter-helm-chart
prometheus-operator-helm-chart
prometheus-postgres-exporter-helm-chart
prometheus-pushgateway-helm-chart
prometheus-rabbitmq-exporter-helm-chart
prometheus-redis-exporter-helm-chart
prometheus-snmp-exporter-helm-chart
prometheus-to-sd-helm-chart
prometheus-helm-chart

This is due to there are some existing repos in prometheus-community
that focus on each component implementation level (e.g. docker image
or stand-alone service). Mixing together might be harder to put on
hub.helm.sh [1]. But, the owners of prometheus-community hold their
right for the final decision.

BTW, would any prometheus-community owners / members explain the
current testing infrastructure? Currently helm chart testing infra is
based on Google Bazel + CircleCI. There's some limitation over there,
e.g. the chart owners / approvers debug the testing infra is hard. I
think all the current prometheus related helm chart owners would like
to know how hard would be for migration / automation.

Best,
Mingchin

On Fri, Jun 19, 2020 at 8:55 PM Stuart Clark
 wrote:


On 2020-06-19 13:30, André Bauer wrote:

Hey guys,

great to see there is already some effort to move the chart out of

the

stable repo :)

As i understand that "prometheus" is not the perfect fit for the

chart

name, as it also installs other components from the prometheus eco
system, i'm also not the biggest fan of umbrella charts.
From our experience at kiwigrid this can lead to updating issues.
For example you'd need to update proemtheus server but because of

the

umbrella it could alreadya fail and exit in the alertmanager

update

step.
Therefore we switched to single chart installs now as you're able

to

update single components, without the need to run the update for

all

charts under the umbrella, which is much more error resistent from

our

experience.

Nevertheless an umbrella chart might be good starting point for
testing Prometheus with all of its available components.

Where i see problems is to deprecate the chart in stable and

change

the way the chart works in the new repo.
Maybe such changes should be done in an earlier step in the stable
chart repo?
At least doumentation of the upgrade path should be clear and
possible, without the need to have manual steps like pvc backup /
restore because the name of the pvc changed.



There are a number of existing charts in the stable repo, which are
mostly for installing indivitual pieces:

prometheus-adapter
prometheus-blackbox-exporter
prometheus-cloudwatch-exporter
prometheus-consul-exporter
prometheus-couchdb-exporter
prometheus-mongodb-exporter
prometheus-mysql-exporter
prometheus-nats-exporter
prometheus-node-exporter
prometheus-operator
prometheus-postgres-exporter
prometheus-pushgateway
prometheus-rabbitmq-exporter
prometheus-redis-exporter
prometheus-snmp-exporter
prometheus-to-sd
prometheus

I'd suggest as a first step to just move them all exactly as they
are
into the prometheus/prometheus-community organisation, and then look
at
making changes later...



Sorry I wasn't clear. You'd expect all those to live in the same repo as 
different directories, rather than different repos. You also need 
somewhere to publish the charts to (e.g. Chartmuseum)


--
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 

Re: [prometheus-developers] Re: Helm charts home

[Mingchin Hsieh]

Hi,

I sort of agree with Stuart's idea; only a little tweak: adding helm-chart
as prefix or suffix. For example,

Prefix approach -
helm-chart-prometheus-adapter
helm-chart-prometheus-blackbox-exporter
helm-chart-prometheus-cloudwatch-exporter
helm-chart-prometheus-consul-exporter
helm-chart-prometheus-couchdb-exporter
helm-chart-prometheus-mongodb-exporter
helm-chart-prometheus-mysql-exporter
helm-chart-prometheus-nats-exporter
helm-chart-prometheus-node-exporter
helm-chart-prometheus-operator
helm-chart-prometheus-postgres-exporter
helm-chart-prometheus-pushgateway
helm-chart-prometheus-rabbitmq-exporter
helm-chart-prometheus-redis-exporter
helm-chart-prometheus-snmp-exporter
helm-chart-prometheus-to-sd
helm-chart-prometheus

Suffix approach -
prometheus-adapter-helm-chart
prometheus-blackbox-exporter-helm-chart
prometheus-cloudwatch-exporter-helm-chart
prometheus-consul-exporter-helm-chart
prometheus-couchdb-exporter-helm-chart
prometheus-mongodb-exporter-helm-chart
prometheus-mysql-exporter-helm-chart
prometheus-nats-exporter-helm-chart
prometheus-node-exporter-helm-chart
prometheus-operator-helm-chart
prometheus-postgres-exporter-helm-chart
prometheus-pushgateway-helm-chart
prometheus-rabbitmq-exporter-helm-chart
prometheus-redis-exporter-helm-chart
prometheus-snmp-exporter-helm-chart
prometheus-to-sd-helm-chart
prometheus-helm-chart

This is due to there are some existing repos in prometheus-community that
focus on each component implementation level (e.g. docker image or
stand-alone service). Mixing together might be harder to put on hub.helm.sh.
But, the owners of prometheus-community hold their right for the final
decision.

BTW, would any prometheus-community owners / members explain the current
testing infrastructure? Currently helm chart testing infra is based on
Google Bazel + CircleCI. There's some limitation over there, e.g. the chart
owners / approvers debug the testing infra is hard. I think all the current
prometheus related helm chart owners would like to know how hard would be
for migration / automation.

Best,
Mingchin

On Fri, Jun 19, 2020 at 8:55 PM Stuart Clark 
wrote:

> On 2020-06-19 13:30, André Bauer wrote:
> > Hey guys,
> >
> > great to see there is already some effort to move the chart out of the
> > stable repo :)
> >
> > As i understand that "prometheus" is not the perfect fit for the chart
> > name, as it also installs other components from the prometheus eco
> > system, i'm also not the biggest fan of umbrella charts.
> > From our experience at kiwigrid this can lead to updating issues.
> > For example you'd need to update proemtheus server but because of the
> > umbrella it could alreadya fail and exit in the alertmanager update
> > step.
> > Therefore we switched to single chart installs now as you're able to
> > update single components, without the need to run the update for all
> > charts under the umbrella, which is much more error resistent from our
> > experience.
> >
> > Nevertheless an umbrella chart might be good starting point for
> > testing Prometheus with all of its available components.
> >
> > Where i see problems is to deprecate the chart in stable and change
> > the way the chart works in the new repo.
> > Maybe such changes should be done in an earlier step in the stable
> > chart repo?
> > At least doumentation of the upgrade path should be clear and
> > possible, without the need to have manual steps like pvc backup /
> > restore because the name of the pvc changed.
> >
>
> There are a number of existing charts in the stable repo, which are
> mostly for installing indivitual pieces:
>
> prometheus-adapter
> prometheus-blackbox-exporter
> prometheus-cloudwatch-exporter
> prometheus-consul-exporter
> prometheus-couchdb-exporter
> prometheus-mongodb-exporter
> prometheus-mysql-exporter
> prometheus-nats-exporter
> prometheus-node-exporter
> prometheus-operator
> prometheus-postgres-exporter
> prometheus-pushgateway
> prometheus-rabbitmq-exporter
> prometheus-redis-exporter
> prometheus-snmp-exporter
> prometheus-to-sd
> prometheus
>
> I'd suggest as a first step to just move them all exactly as they are
> into the prometheus/prometheus-community organisation, and then look at
> making changes later...
>
> --
> 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
> 

Re: [prometheus-developers] Re: Helm charts home

[Stuart Clark]

On 2020-06-19 13:30, André Bauer wrote:

Hey guys,

great to see there is already some effort to move the chart out of the
stable repo :)

As i understand that "prometheus" is not the perfect fit for the chart
name, as it also installs other components from the prometheus eco
system, i'm also not the biggest fan of umbrella charts.
From our experience at kiwigrid this can lead to updating issues.
For example you'd need to update proemtheus server but because of the
umbrella it could alreadya fail and exit in the alertmanager update
step.
Therefore we switched to single chart installs now as you're able to
update single components, without the need to run the update for all
charts under the umbrella, which is much more error resistent from our
experience.

Nevertheless an umbrella chart might be good starting point for
testing Prometheus with all of its available components.

Where i see problems is to deprecate the chart in stable and change
the way the chart works in the new repo.
Maybe such changes should be done in an earlier step in the stable
chart repo?
At least doumentation of the upgrade path should be clear and
possible, without the need to have manual steps like pvc backup /
restore because the name of the pvc changed.



There are a number of existing charts in the stable repo, which are 
mostly for installing indivitual pieces:


prometheus-adapter
prometheus-blackbox-exporter
prometheus-cloudwatch-exporter
prometheus-consul-exporter
prometheus-couchdb-exporter
prometheus-mongodb-exporter
prometheus-mysql-exporter
prometheus-nats-exporter
prometheus-node-exporter
prometheus-operator
prometheus-postgres-exporter
prometheus-pushgateway
prometheus-rabbitmq-exporter
prometheus-redis-exporter
prometheus-snmp-exporter
prometheus-to-sd
prometheus

I'd suggest as a first step to just move them all exactly as they are 
into the prometheus/prometheus-community organisation, and then look at 
making changes later...


--
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/c4449085447c54f8ef66a04905ee397e%40Jahingo.com.

Re: [prometheus-developers] Re: Helm charts home

[André Bauer]

Hey guys,

great to see there is already some effort to move the chart out of the 
stable repo :)

As i understand that "prometheus" is not the perfect fit for the chart 
name, as it also installs other components from the prometheus eco system, 
i'm also not the biggest fan of umbrella charts.
>From our experience at kiwigrid this can lead to updating issues.
For example you'd need to update proemtheus server but because of the 
umbrella it could alreadya fail and exit in the alertmanager update step.
Therefore we switched to single chart installs now as you're able to update 
single components, without the need to run the update for all charts under 
the umbrella, which is much more error resistent from our experience.

Nevertheless an umbrella chart might be good starting point for testing 
Prometheus with all of its available components.

Where i see problems is to deprecate the chart in stable and change the way 
the chart works in the new repo.
Maybe such changes should be done in an earlier step in the stable chart 
repo?
At least doumentation of the upgrade path should be clear and possible, 
without the need to have manual steps like pvc backup / restore because the 
name of the pvc changed.

Kind regards
André


Naseem Ullah schrieb am Montag, 15. Juni 2020 um 03:13:57 UTC+2:

> Yes a single repo called helm-charts to host all charts.
>
> Also, as per 
> https://prometheus.io/docs/introduction/overview/#architecture we should 
> have a prometheus-server chart that would be part of the umbrella 
> prometheus chart if we want to follow this pattern.
>
>
> On Sunday, June 14, 2020 at 12:32:26 PM UTC-4, Augustin Husson wrote:
>
>> Or just helm-chart with inside all chart relative to the prometheus tools 
>> like node-exporter, alertmanager ...etc.
>>
>> Le dim. 14 juin 2020 à 13:52, Mingchin Hsieh  a 
>> écrit :
>>
> Hi Frederic,
>>>
>>> Yes. I think I would keep straightforward naming as 
>>> prometheus-helm-chart, i.e. 
>>>
>>> https://github.com/prometheus-community/prometheus-helm-chart
>>>
>>> If you guys have better idea on naming, please advice.
>>>
>>> Best,
>>>
>> Ming 
>>>
>>> On Tuesday, June 9, 2020 at 6:44:26 PM UTC+8, Frederic Branczyk wrote:
>>>
>> I personally think the amount of things happening in these charts is too 
 big to represent "prometheus". Same goes for the prometheus-operator 
 chart. 
 Both of these cover a very large surface and as a result issues frequently 
 get filed against the upstream projects confusing problems with the charts 
 with the scope of the projects themselves.

 If a chart was in the community org then it should really only deploy 
 and configure Prometheus in my opinion. Meta charts that configure 
 multiple 
 sub-charts would be ok, but under a different name (which is why we called 
 the project that integrates the two worlds tightly with each other 
 kube-prometheus ).

 On Thu, 4 Jun 2020 at 23:50, Mingchin Hsieh  wrote:

>>> Hi guys, 
>
> I am one of Helm Prometheus chart maintainers:
>
>
> https://github.com/helm/charts/blob/master/stable/prometheus/Chart.yaml#L18
>
> I hope I could help to move Helm Prometheus chart for looking new 
> home. If after deprecation date, I will host it on my personal repo.
>
> Best,
> Ming
>
> On Tuesday, March 31, 2020 at 11:38:58 AM UTC+8, Naseem Ullah wrote:
>>
>> As per the helm charts stable repo deprecation timeline 
>> , the various 
>> prometheus related helm charts such as prometheus 
>> ,
>>  prometheus-operator 
>> 
>> , prometheus-adapter 
>> 
>> , prometheus-node-exporter 
>> 
>>  and 
>> the various other exporters will require a new home and none more 
>> fitting 
>> than https://github.com/prometheus-community.We have had successful 
>> migrations of the sort with other CNCF projects, namely Jaeger (
>> https://github.com/jaegertracing/helm-charts)  and Fluent Bit(
>> https://github.com/fluent/helm-charts).
>>
> -- 
> 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+unsub...@googlegroups.com.


> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/prometheus-developers/53909810-686f-4550-977a-4f1c721dc8fao%40googlegroups.com
>  
> 

Re: [prometheus-developers] Re: Helm charts home

[Naseem Ullah]

Yes a single repo called helm-charts to host all charts.

Also, as per https://prometheus.io/docs/introduction/overview/#architecture we 
should have a prometheus-server chart that would be part of the umbrella 
prometheus chart if we want to follow this pattern.

On Sunday, June 14, 2020 at 12:32:26 PM UTC-4, Augustin Husson wrote:
>
> Or just helm-chart with inside all chart relative to the prometheus tools 
> like node-exporter, alertmanager ...etc.
>
> Le dim. 14 juin 2020 à 13:52, Mingchin Hsieh  > a écrit :
>
>> Hi Frederic,
>>
>> Yes. I think I would keep straightforward naming as 
>> prometheus-helm-chart, i.e. 
>>
>> https://github.com/prometheus-community/prometheus-helm-chart
>>
>> If you guys have better idea on naming, please advice.
>>
>> Best,
>> Ming 
>>
>> On Tuesday, June 9, 2020 at 6:44:26 PM UTC+8, Frederic Branczyk wrote:
>>>
>>> I personally think the amount of things happening in these charts is too 
>>> big to represent "prometheus". Same goes for the prometheus-operator chart. 
>>> Both of these cover a very large surface and as a result issues frequently 
>>> get filed against the upstream projects confusing problems with the charts 
>>> with the scope of the projects themselves.
>>>
>>> If a chart was in the community org then it should really only deploy 
>>> and configure Prometheus in my opinion. Meta charts that configure multiple 
>>> sub-charts would be ok, but under a different name (which is why we called 
>>> the project that integrates the two worlds tightly with each other 
>>> kube-prometheus ).
>>>
>>> On Thu, 4 Jun 2020 at 23:50, Mingchin Hsieh  wrote:
>>>
 Hi guys, 

 I am one of Helm Prometheus chart maintainers:


 https://github.com/helm/charts/blob/master/stable/prometheus/Chart.yaml#L18

 I hope I could help to move Helm Prometheus chart for looking new home. 
 If after deprecation date, I will host it on my personal repo.

 Best,
 Ming

 On Tuesday, March 31, 2020 at 11:38:58 AM UTC+8, Naseem Ullah wrote:
>
> As per the helm charts stable repo deprecation timeline 
> , the various 
> prometheus related helm charts such as prometheus 
> ,
>  prometheus-operator 
> 
> , prometheus-adapter 
> 
> , prometheus-node-exporter 
> 
>  and 
> the various other exporters will require a new home and none more fitting 
> than https://github.com/prometheus-community.We have had successful 
> migrations of the sort with other CNCF projects, namely Jaeger (
> https://github.com/jaegertracing/helm-charts)  and Fluent Bit(
> https://github.com/fluent/helm-charts).
>
 -- 
 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/53909810-686f-4550-977a-4f1c721dc8fao%40googlegroups.com
  
 
 .

>>> -- 
>> 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/d4b915e1-e758-4c8f-b747-15a795705e8fo%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/f5cc3fdd-0a26-4657-82d3-1086417505cao%40googlegroups.com.

Re: [prometheus-developers] Re: Helm charts home

[Augustin Husson]

Or just helm-chart with inside all chart relative to the prometheus tools
like node-exporter, alertmanager ...etc.

Le dim. 14 juin 2020 à 13:52, Mingchin Hsieh  a écrit :

> Hi Frederic,
>
> Yes. I think I would keep straightforward naming as prometheus-helm-chart,
> i.e.
>
> https://github.com/prometheus-community/prometheus-helm-chart
>
> If you guys have better idea on naming, please advice.
>
> Best,
> Ming
>
> On Tuesday, June 9, 2020 at 6:44:26 PM UTC+8, Frederic Branczyk wrote:
>>
>> I personally think the amount of things happening in these charts is too
>> big to represent "prometheus". Same goes for the prometheus-operator chart.
>> Both of these cover a very large surface and as a result issues frequently
>> get filed against the upstream projects confusing problems with the charts
>> with the scope of the projects themselves.
>>
>> If a chart was in the community org then it should really only deploy and
>> configure Prometheus in my opinion. Meta charts that configure multiple
>> sub-charts would be ok, but under a different name (which is why we called
>> the project that integrates the two worlds tightly with each other
>> kube-prometheus ).
>>
>> On Thu, 4 Jun 2020 at 23:50, Mingchin Hsieh  wrote:
>>
>>> Hi guys,
>>>
>>> I am one of Helm Prometheus chart maintainers:
>>>
>>>
>>> https://github.com/helm/charts/blob/master/stable/prometheus/Chart.yaml#L18
>>>
>>> I hope I could help to move Helm Prometheus chart for looking new home.
>>> If after deprecation date, I will host it on my personal repo.
>>>
>>> Best,
>>> Ming
>>>
>>> On Tuesday, March 31, 2020 at 11:38:58 AM UTC+8, Naseem Ullah wrote:

 As per the helm charts stable repo deprecation timeline
 , the various
 prometheus related helm charts such as prometheus
 ,
  prometheus-operator
 
 , prometheus-adapter
 
 , prometheus-node-exporter
 
  and
 the various other exporters will require a new home and none more fitting
 than https://github.com/prometheus-community.We have had successful
 migrations of the sort with other CNCF projects, namely Jaeger (
 https://github.com/jaegertracing/helm-charts)  and Fluent Bit(
 https://github.com/fluent/helm-charts).

>>> --
>>> 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/53909810-686f-4550-977a-4f1c721dc8fao%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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/d4b915e1-e758-4c8f-b747-15a795705e8fo%40googlegroups.com
> 
> .
>

-- 
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/CAOJizGc9FRUY532fevasWa4PG8T0_0uErZPiF8FqXL04BRk0ew%40mail.gmail.com.

Re: [prometheus-developers] Re: Helm charts home

[Mingchin Hsieh]

Hi Frederic,

Yes. I think I would keep straightforward naming as prometheus-helm-chart, 
i.e. 

https://github.com/prometheus-community/prometheus-helm-chart

If you guys have better idea on naming, please advice.

Best,
Ming 

On Tuesday, June 9, 2020 at 6:44:26 PM UTC+8, Frederic Branczyk wrote:
>
> I personally think the amount of things happening in these charts is too 
> big to represent "prometheus". Same goes for the prometheus-operator chart. 
> Both of these cover a very large surface and as a result issues frequently 
> get filed against the upstream projects confusing problems with the charts 
> with the scope of the projects themselves.
>
> If a chart was in the community org then it should really only deploy and 
> configure Prometheus in my opinion. Meta charts that configure multiple 
> sub-charts would be ok, but under a different name (which is why we called 
> the project that integrates the two worlds tightly with each other 
> kube-prometheus ).
>
> On Thu, 4 Jun 2020 at 23:50, Mingchin Hsieh  > wrote:
>
>> Hi guys, 
>>
>> I am one of Helm Prometheus chart maintainers:
>>
>>
>> https://github.com/helm/charts/blob/master/stable/prometheus/Chart.yaml#L18
>>
>> I hope I could help to move Helm Prometheus chart for looking new home. 
>> If after deprecation date, I will host it on my personal repo.
>>
>> Best,
>> Ming
>>
>> On Tuesday, March 31, 2020 at 11:38:58 AM UTC+8, Naseem Ullah wrote:
>>>
>>> As per the helm charts stable repo deprecation timeline 
>>> , the various 
>>> prometheus related helm charts such as prometheus 
>>> ,
>>>  prometheus-operator 
>>> 
>>> , prometheus-adapter 
>>> , 
>>> prometheus-node-exporter 
>>> 
>>>  and 
>>> the various other exporters will require a new home and none more fitting 
>>> than https://github.com/prometheus-community.We have had successful 
>>> migrations of the sort with other CNCF projects, namely Jaeger (
>>> https://github.com/jaegertracing/helm-charts)  and Fluent Bit(
>>> https://github.com/fluent/helm-charts).
>>>
>> -- 
>> 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/53909810-686f-4550-977a-4f1c721dc8fao%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/d4b915e1-e758-4c8f-b747-15a795705e8fo%40googlegroups.com.

Re: [prometheus-developers] Re: Helm charts home

[Naseem Ullah]

The Prometheus chart clearly has optional installable sub chart for ksm: 
https://github.com/helm/charts/blob/master/stable/prometheus/requirements.yaml
We can factor our alertmanager with this chart I've prepared: 
https://github.com/naseemkullah/naseem-charts/tree/master/charts/alertmanager
We can also factor our node exporter with either a new node-exporter chart 
or 
https://github.com/helm/charts/tree/master/stable/prometheus-node-exporter

We are ready to get going, I've had success migrating other CNCF charts 
such as https://github.com/jaegertracing/helm-charts and 
https://github.com/fluent/helm-charts/tree/master/charts/fluent-bit

Please allow me to lead this effort by providing an empty helm-charts repo 
under https://github.com/prometheus-community.

After we have prometheus, node-exporter, alertmanager and the various 
communicty maintained exporter charts hosted, we can discuss a way forward 
for prometheus operator such that Frederic is on board.

On Tuesday, June 9, 2020 at 12:15:27 PM UTC-4, Frederic Branczyk wrote:
>
> I wasn't saying they don't have their place, I'm saying they both do too 
> much to accurately match their name. The prometheus chart should only be 
> about deploying prometheus, and nothing else, as in no additional exporters 
> etc. and neither should the prometheus-operator chart, it should only 
> deploy the prometheus-operator and nothing else.
>
> There is a place for higher level/meta packages, but not named 
> "prometheus" or "prometheus-operator" is all I'm saying.
>
> On Tue, 9 Jun 2020 at 15:43, Stuart Clark  > wrote:
>
>> On 09/06/2020 13:15, David Karlsen wrote:
>> > +1
>> > Single chart for single components, and then an umbrella-chart can 
>> > bring all of them together - then people can select whatever is most 
>> > appropriate.
>> >
>> >
>>
>> Prometheus Operator & generic Prometheus are two different things, and 
>> the existing Helm repo reflects that.
>>
>> You can use the various individual Helm charts to install Prometheus, 
>> Alertmanager, Grafana and various exporters and then manually plumb 
>> things together.
>>
>> Alternatively Prometheus Operator mixes in some extra magic using 
>> slightly customised deployments (using the Prometheus Operator chart) to 
>> allow decentralised configuration using different CRDs (ServiceMonitors 
>> for what to scrape, alert rules, instances, etc.)
>>
>> So both have their place.
>>
>> -- 
>> 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/4561bda4-af10-4e16-a035-e3173cefe2bdo%40googlegroups.com.

Re: [prometheus-developers] Re: Helm charts home

[Naseem Ullah]

The Prometheus chart clearly has optional installable sub chart for ksm: 
https://github.com/helm/charts/blob/master/stable/prometheus/requirements.yaml
We can factor our alertmanager with this chart I've prepared: 
https://github.com/naseemkullah/naseem-charts/tree/master/charts/alertmanager
We can also factor our node exporter with either a new node-exporter chart 
or 
https://github.com/helm/charts/tree/master/stable/prometheus-node-exporter

We are ready to get going, I've had success migrating other CNCF charts 
such as https://github.com/jaegertracing/helm-charts and 
https://github.com/fluent/helm-charts/tree/master/charts/fluent-bit

Please allow me to lead this effort by providing an empty helm-charts repo 
under https://github.com/prometheus-community.

After we have prometheus, node-exporter, alert-manager and the various 
exporter charts hosted, we can discuss prometheus operator with to be such 
that Frederic is on board.

On Tuesday, June 9, 2020 at 12:15:27 PM UTC-4, Frederic Branczyk wrote:
>
> I wasn't saying they don't have their place, I'm saying they both do too 
> much to accurately match their name. The prometheus chart should only be 
> about deploying prometheus, and nothing else, as in no additional exporters 
> etc. and neither should the prometheus-operator chart, it should only 
> deploy the prometheus-operator and nothing else.
>
> There is a place for higher level/meta packages, but not named 
> "prometheus" or "prometheus-operator" is all I'm saying.
>
> On Tue, 9 Jun 2020 at 15:43, Stuart Clark  > wrote:
>
>> On 09/06/2020 13:15, David Karlsen wrote:
>> > +1
>> > Single chart for single components, and then an umbrella-chart can 
>> > bring all of them together - then people can select whatever is most 
>> > appropriate.
>> >
>> >
>>
>> Prometheus Operator & generic Prometheus are two different things, and 
>> the existing Helm repo reflects that.
>>
>> You can use the various individual Helm charts to install Prometheus, 
>> Alertmanager, Grafana and various exporters and then manually plumb 
>> things together.
>>
>> Alternatively Prometheus Operator mixes in some extra magic using 
>> slightly customised deployments (using the Prometheus Operator chart) to 
>> allow decentralised configuration using different CRDs (ServiceMonitors 
>> for what to scrape, alert rules, instances, etc.)
>>
>> So both have their place.
>>
>> -- 
>> 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/ac75d9ca-d5c1-4c77-aad2-991bbc9c9889o%40googlegroups.com.

Re: [prometheus-developers] Re: Helm charts home

[Naseem Ullah]

The Prometheus chart clearly has optional installable sub chart for ksm.
We can factor our alertmanager with this chart I've prepared: 
https://github.com/helm/charts/blob/master/stable/prometheus/requirements.yaml
We can also factor our node exporter with either a new node-exporter chart 
or 
https://github.com/helm/charts/tree/master/stable/prometheus-node-exporter

We are ready to get going, I've had success migrating other CNCF charts 
such as https://github.com/jaegertracing/helm-charts and 
https://github.com/fluent/helm-charts/tree/master/charts/fluent-bit

Please allow me to lead this effort by providing an empty helm-charts repo 
under https://github.com/prometheus-community.

On Tuesday, June 9, 2020 at 12:15:27 PM UTC-4, Frederic Branczyk wrote:
>
> I wasn't saying they don't have their place, I'm saying they both do too 
> much to accurately match their name. The prometheus chart should only be 
> about deploying prometheus, and nothing else, as in no additional exporters 
> etc. and neither should the prometheus-operator chart, it should only 
> deploy the prometheus-operator and nothing else.
>
> There is a place for higher level/meta packages, but not named 
> "prometheus" or "prometheus-operator" is all I'm saying.
>
> On Tue, 9 Jun 2020 at 15:43, Stuart Clark  > wrote:
>
>> On 09/06/2020 13:15, David Karlsen wrote:
>> > +1
>> > Single chart for single components, and then an umbrella-chart can 
>> > bring all of them together - then people can select whatever is most 
>> > appropriate.
>> >
>> >
>>
>> Prometheus Operator & generic Prometheus are two different things, and 
>> the existing Helm repo reflects that.
>>
>> You can use the various individual Helm charts to install Prometheus, 
>> Alertmanager, Grafana and various exporters and then manually plumb 
>> things together.
>>
>> Alternatively Prometheus Operator mixes in some extra magic using 
>> slightly customised deployments (using the Prometheus Operator chart) to 
>> allow decentralised configuration using different CRDs (ServiceMonitors 
>> for what to scrape, alert rules, instances, etc.)
>>
>> So both have their place.
>>
>> -- 
>> 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/cda40f08-08f4-4723-abc0-09a2fe2326d5o%40googlegroups.com.

Re: [prometheus-developers] Re: Helm charts home

[Frederic Branczyk]

I wasn't saying they don't have their place, I'm saying they both do too
much to accurately match their name. The prometheus chart should only be
about deploying prometheus, and nothing else, as in no additional exporters
etc. and neither should the prometheus-operator chart, it should only
deploy the prometheus-operator and nothing else.

There is a place for higher level/meta packages, but not named "prometheus"
or "prometheus-operator" is all I'm saying.

On Tue, 9 Jun 2020 at 15:43, Stuart Clark  wrote:

> On 09/06/2020 13:15, David Karlsen wrote:
> > +1
> > Single chart for single components, and then an umbrella-chart can
> > bring all of them together - then people can select whatever is most
> > appropriate.
> >
> >
>
> Prometheus Operator & generic Prometheus are two different things, and
> the existing Helm repo reflects that.
>
> You can use the various individual Helm charts to install Prometheus,
> Alertmanager, Grafana and various exporters and then manually plumb
> things together.
>
> Alternatively Prometheus Operator mixes in some extra magic using
> slightly customised deployments (using the Prometheus Operator chart) to
> allow decentralised configuration using different CRDs (ServiceMonitors
> for what to scrape, alert rules, instances, etc.)
>
> So both have their place.
>
> --
> 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/CAOs1UmzHcEWp6SaPgE0Rg65PXJer0in%3DBDD0Qha8%3DV%3D%3DMh3gQQ%40mail.gmail.com.

Re: [prometheus-developers] Re: Helm charts home

[Stuart Clark]

On 09/06/2020 13:15, David Karlsen wrote:

+1
Single chart for single components, and then an umbrella-chart can 
bring all of them together - then people can select whatever is most 
appropriate.





Prometheus Operator & generic Prometheus are two different things, and 
the existing Helm repo reflects that.


You can use the various individual Helm charts to install Prometheus, 
Alertmanager, Grafana and various exporters and then manually plumb 
things together.


Alternatively Prometheus Operator mixes in some extra magic using 
slightly customised deployments (using the Prometheus Operator chart) to 
allow decentralised configuration using different CRDs (ServiceMonitors 
for what to scrape, alert rules, instances, etc.)


So both have their place.

--
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/2417983d-7501-c3e3-f34f-715792cdbae6%40Jahingo.com.

Re: [prometheus-developers] Re: Helm charts home

[David Karlsen]

+1
Single chart for single components, and then an umbrella-chart can bring
all of them together - then people can select whatever is most appropriate.



tir. 9. jun. 2020 kl. 12:44 skrev Frederic Branczyk :

> I personally think the amount of things happening in these charts is too
> big to represent "prometheus". Same goes for the prometheus-operator chart.
> Both of these cover a very large surface and as a result issues frequently
> get filed against the upstream projects confusing problems with the charts
> with the scope of the projects themselves.
>
> If a chart was in the community org then it should really only deploy and
> configure Prometheus in my opinion. Meta charts that configure multiple
> sub-charts would be ok, but under a different name (which is why we called
> the project that integrates the two worlds tightly with each other
> kube-prometheus ).
>
> On Thu, 4 Jun 2020 at 23:50, Mingchin Hsieh  wrote:
>
>> Hi guys,
>>
>> I am one of Helm Prometheus chart maintainers:
>>
>>
>> https://github.com/helm/charts/blob/master/stable/prometheus/Chart.yaml#L18
>>
>> I hope I could help to move Helm Prometheus chart for looking new home.
>> If after deprecation date, I will host it on my personal repo.
>>
>> Best,
>> Ming
>>
>> On Tuesday, March 31, 2020 at 11:38:58 AM UTC+8, Naseem Ullah wrote:
>>>
>>> As per the helm charts stable repo deprecation timeline
>>> , the various
>>> prometheus related helm charts such as prometheus
>>> ,
>>>  prometheus-operator
>>> 
>>> , prometheus-adapter
>>> ,
>>> prometheus-node-exporter
>>> 
>>>  and
>>> the various other exporters will require a new home and none more fitting
>>> than https://github.com/prometheus-community.We have had successful
>>> migrations of the sort with other CNCF projects, namely Jaeger (
>>> https://github.com/jaegertracing/helm-charts)  and Fluent Bit(
>>> https://github.com/fluent/helm-charts).
>>>
>> --
>> 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/53909810-686f-4550-977a-4f1c721dc8fao%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAOs1UmwkV8vMu%2BgEZ0kHNnJXMER%2BuNboSr_WxKnAWnv2J40gmA%40mail.gmail.com
> 
> .
>


-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

-- 
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/CAGO7Ob1zAwGihxhjOsDRYDzm8EWbBUweEvt0XzJdWEUmfAe%2BhA%40mail.gmail.com.

Re: [prometheus-developers] Re: Helm charts home

[Frederic Branczyk]

I personally think the amount of things happening in these charts is too
big to represent "prometheus". Same goes for the prometheus-operator chart.
Both of these cover a very large surface and as a result issues frequently
get filed against the upstream projects confusing problems with the charts
with the scope of the projects themselves.

If a chart was in the community org then it should really only deploy and
configure Prometheus in my opinion. Meta charts that configure multiple
sub-charts would be ok, but under a different name (which is why we called
the project that integrates the two worlds tightly with each other
kube-prometheus ).

On Thu, 4 Jun 2020 at 23:50, Mingchin Hsieh  wrote:

> Hi guys,
>
> I am one of Helm Prometheus chart maintainers:
>
> https://github.com/helm/charts/blob/master/stable/prometheus/Chart.yaml#L18
>
> I hope I could help to move Helm Prometheus chart for looking new home. If
> after deprecation date, I will host it on my personal repo.
>
> Best,
> Ming
>
> On Tuesday, March 31, 2020 at 11:38:58 AM UTC+8, Naseem Ullah wrote:
>>
>> As per the helm charts stable repo deprecation timeline
>> , the various
>> prometheus related helm charts such as prometheus
>> ,
>>  prometheus-operator
>> ,
>> prometheus-adapter
>> ,
>> prometheus-node-exporter
>>  
>> and
>> the various other exporters will require a new home and none more fitting
>> than https://github.com/prometheus-community.We have had successful
>> migrations of the sort with other CNCF projects, namely Jaeger (
>> https://github.com/jaegertracing/helm-charts)  and Fluent Bit(
>> https://github.com/fluent/helm-charts).
>>
> --
> 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/53909810-686f-4550-977a-4f1c721dc8fao%40googlegroups.com
> 
> .
>

-- 
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/CAOs1UmwkV8vMu%2BgEZ0kHNnJXMER%2BuNboSr_WxKnAWnv2J40gmA%40mail.gmail.com.

Re: [prometheus-developers] Re: Helm charts home

[Julius Volz]

Ping... Ben, any opinion on how to proceed?

On Thu, Apr 16, 2020 at 2:24 PM Julius Volz  wrote:

> +cc SuperQ (Ben)
>
> Sounds reasonable to me at a first glance.
>
> On Wed, Apr 15, 2020 at 2:56 PM Naseem Ullah  wrote:
>
>> bump
>>
>> --
>> 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/42f0df44-4264-4462-8456-0da6cfd42703%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CA%2BT6YozT-pUzD2xMVQp1XWhfB%2BKFrA7zoRddvWW3tXM57Mhsgw%40mail.gmail.com.

Re: [prometheus-developers] Re: Helm charts home

[Julius Volz]

+cc SuperQ (Ben)

Sounds reasonable to me at a first glance.

On Wed, Apr 15, 2020 at 2:56 PM Naseem Ullah  wrote:

> bump
>
> --
> 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/42f0df44-4264-4462-8456-0da6cfd42703%40googlegroups.com
> 
> .
>

-- 
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/CA%2BT6YozudUtNgG6ryjEqez%3D3raqCAj2Re-go8egULsUvKdiDLw%40mail.gmail.com.