Helm charts home

[Naseem Ullah]

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

[Naseem Ullah]

bump

[Julius Volz]

+cc SuperQ (Ben)

Sounds reasonable to me at a first glance.

On Wed, Apr 15, 2020 at 2:56 PM Naseem Ullah <nas...@transit.app> 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-devel...@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.

[Julius Volz]

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

[Mingchin Hsieh]

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

[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).

--

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

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

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

[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

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

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

[Mingchin Hsieh]

Hi Naseem,

I think we could start from https://github.com/prometheus-community.

Could any admin member of prometheus-community create prometheus helm chart repo there? If they can, then next step would be a deprecation notice on current prometheus helm chart PR and I will approve it as handover. Another step is to post it on hub.helm.sh.

I truly hope this could be done before Nov. 2020 deadline.

Thank you and other guys for providing me fantastic advices.

Best,

Ming

[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 

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.

[Augustin Husson]

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

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@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-devel...@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.

[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 <zanh...@gmail.com> 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 <zanh...@gmail.com> 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.

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

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

[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

[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

--
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/c4449085447c54f8ef66a04905ee397e%40Jahingo.com.

[Stuart Clark]

> hub.helm.sh [1]. But, the owners of prometheus-community hold their

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

[Mingchin Hsieh]

Hi Stuart,

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

Best,

Mingchin

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

[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

--

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-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/171848ab-82d2-4fab-ad16-c37f98d7dc49n%40googlegroups.com.

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAL251fp%3D78fH6pxtdWxKRcFEQTiKSW7mZP6T1Y72FftxSWBHug%40mail.gmail.com.

[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).

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

--
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-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/1bab5efa-a52b-449e-865a-4c84273a2f8co%40googlegroups.com.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAL251fpkeg2849HbO-3JTGJ0LTBvOUDpix99nAPQuVMV4A5jpg%40mail.gmail.com.

[Mingchin Hsieh]

Hi Augustin,

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

Best,

Mingchin

[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

[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 :)

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

[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