prometheus-community
[kube-prometheus-stack] Adding support for Grafana Operator
What this PR does / why we need it:
This PR is adding the possibility to use Grafana Operator instead of the simple Grafana instance. The main driver is to be able to use the GrafanaDashboard and GrafanaDatasource custom resources instead of ConfigMap.
Which issue this PR fixes
- related to issue #1418
Special notes for your reviewer:
The looks so big because all the auto-generated dashboards from templates/dashboards-1.14 were moved to the top level of the chart and are now shared across the templates/grafana and templates/grafana-operator templates.
Checklist
- [x] DCO signed
- [x] Chart Version bumped
- [x] Title of the PR starts with chart name
Thank you for your comment, @monotek. You could say the same about the grafana chart as well. The advantage of having the Grafana Operator as a part this chart is that people get automatically configured datasource as well as all the dashboards in their Grafana instance and they can keep extending it through standard GrafanaDataSource and GrafanaDashboard custom resources that goes through CRD validation during the installation. That's something that's hard to achieve through configuration pushed via ConfigMap without any operator or validating wekbook.
@andrewgkew @bismarck @desaintmartin @gianrubio @gkarthiks @scottrigby @Xtigyro Please could I ask you for your review?
Adding this optional functionality to the be able to use the custom resources provided by Grafana Operator when using this chart would be a huge advantage.
The current option of disabling Grafana in this chart and adding to the Grafana Operator chart means having to manage the out of the box dashboards. These dashboards are so frequently deployed that end users expect them to be available and doing so separately and keeping them up to date is a problem
@andrewgkew @bismarck @desaintmartin @gianrubio @gkarthiks @scottrigby @Xtigyro Please could review this PR?
Having Grafana Operator bundled together with a Prometheus Operator will help to address multi-tenanted environments, where at the moment, we need to deploy a separate Grafana Helm chart together with Prometheus CR in order to create a dedicated monitoring stack for every developer team.
Apart from the above, it also unifies the experience of managing all kube-prom-stack resources:
- Prometheus instances
- AlertManager instances
- Grafana instances
- Prometheus resources: rules, monitors, etc
- Grafana resources: dashboards, datasources, notification channels
In other words, you're just one CR away from your entire monitoring stack, which hugely simplifies deployment and is one of the main goals of this project.
The other huge benefit I see is the ability to define dashboards via CRD. Apart from automated validation of resources and ease of error discovery through a status field, the user will get the ability to author dashboards with jsonnet, add plugin requirements, map datasources, and manage folders.
@monotek it looks like you are the only person who cares about this Helm chart as the rest of the assigned reviewers don't bother to provide any feedback. Please could you reconsider this PR in regards of the feedback from the community above?
@monotek @andrewgkew @bismarck @desaintmartin @gianrubio @gkarthiks @scottrigby @Xtigyro Can you guys review and/or comment on this PR? I think this PR will make life easier for many of us, especially for those running heterogeneous (k8s and OpenShift) multi-tenanted environments.
Seems like a valid use-case, maybe we should reconsider this.
Does any grafana-operator users tested the PR chart?
@jtyr @monotek @dwalker-sabiogroup @vladimir-babichev
I still dislike the idea. The grafana operator can be installed separately easily while disabling the internal grafana with a single value.
Besides the grafana operator is not even maintained by the grafana community and the values.yaml and chart.yaml files of the kube Prometheus chart will be blown up even more with a redundant option.
If you don't like the idea, maybe we should close this PR then? Unless there's hope for them? If yes how?
If not, I'll guess they could make a chart with kube-prometheus-stack, grafana-operator and whatever they need on their side.
Both options LGTM
I'm not a maintainer of the chart, so i would not be in the way if the maintainers think it's a good idea.
My bad... I thought you were because it seems you're the most active on this chart/repository.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
Adding any chart from https://charts.bitnami.com/bitnami as dependency is always a really bad idea.
Bitnami has some retention policies on the chart repository, e.g. they remove older chart version from the repo.
https://github.com/bitnami/charts/issues/10539
At some point, older kube-prometheus-stack version can not be installed anymore, if the grafana-operator version is not longer available.
I personally would not pull the grafana-operator helm chart into this stack.
From my point of view, if kube-prometheus-stack exposes GrafanaDataSource and GrafanaDashboard CR, it would be sufficient to support the Grafana Operator. Users can bundle the installation with an local umbrella chart.
Adding any chart from https://charts.bitnami.com/bitnami as dependency is always a really bad idea. Bitnami has some retention policies on the chart repository, e.g. they remove older chart version from the repo. https://github.com/bitnami/charts/issues/10539 At some point, older kube-prometheus-stack version can not be installed anymore, if the grafana-operator version is not longer available.
I believe it shouldn't be a problem, as helm packages all dependency charts into one single .tgz file. It does so, to specifically resolve dependency management problem.
From my point of view, if kube-prometheus-stack exposes GrafanaDataSource and GrafanaDashboard CR, it would be sufficient to support the Grafana Operator. Users can bundle the installation with an local umbrella chart.
kube-prometheus-stack is an "uber" chart that does everything for you out of the box, hence it makes grafana-operator a perfect fit for it. But for sure, there should be an option to disable operator installation, if somebody would prefer not to deploy one.
The other problem, I personally find, is the lack of prometheus-operator chart that installs the operator itself with its CRDs. Having one would resolve issues like this, as users could create wrapper charts and bundle dependencies according to their needs.
Hi
Has there been any progress on this?
I would like to help get this through. However I would like to move away from the bitnami charts as they don't support arm as of yet.
Edit: I cannot seem to find another non bitnami helm chart
Any thoughts
Thanks
@rhysxevans I don't believe there is non-bitnami chart for grafana-operator, but there is an official image published to quay.io that has arm builds.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
Bitnami has just released arm support for the majority of their images apparently https://blog.bitnami.com/2023/02/bitnami-arm-containers-available-at.html?m=1 and https://hub.docker.com/r/bitnami/grafana-operator/tags
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.