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 < [email protected]> 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 <[email protected]> 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 <[email protected]> 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. >>>> >>>> >>>> >>>> [email protected] 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 <[email protected]> >>>>> 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 >>>>>> > <[email protected]> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/1bab5efa-a52b-449e-865a-4c84273a2f8co%40googlegroups.com > <https://groups.google.com/d/msgid/prometheus-developers/1bab5efa-a52b-449e-865a-4c84273a2f8co%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAL251fpkeg2849HbO-3JTGJ0LTBvOUDpix99nAPQuVMV4A5jpg%40mail.gmail.com.
