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 <stuart.cl...@jahingo.com>
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
> > <stuart.cl...@jahingo.com> 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 
https://groups.google.com/d/msgid/prometheus-developers/CAL251frekz9FnBPEY1YtKWPJgtyXugJ7v0kOL251phzT3AmuKw%40mail.gmail.com.

Reply via email to