-
Notifications
You must be signed in to change notification settings - Fork 16.8k
[stable/grafana] Support Provisioner Configuration #3514
Conversation
/assign @linki |
/assign @prydonius |
/unassign @linki |
Looking forward to this to land. Too bad though that creating a default datasource for e.g. Prometheus deployed by the stable Chart (in a Chart having both Grafana and Prometheus as requirements) still won't be possible using this approach, because its service name/DNS entry depends on the Helm release name 😞 |
@BugRoger |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: BugRoger Assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixed. It was just some other change increasing the version |
/assign @prydonius |
Can confirm that it works like a charm and grafana 5.0.0 was just released |
@@ -83,6 +83,14 @@ spec: | |||
resources: | |||
{{ toYaml .Values.server.resources | indent 12 }} | |||
volumeMounts: | |||
{{- if .Values.provisioningDatasourcesFiles }} | |||
- name: provisioning-volume | |||
mountPath: {{ default "/var/lib/grafana/provisioning" .Values.server.provisioningLocalPath }}/datasources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't use the default
function. Defaults come from values.yaml
anyways which is better. Apply to all your changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured this is common practice in the chart. So, let's leave it for now. Would be cool to get that fixed in a separate PR.
/ok-to-test |
/retest |
This merge proposal doesn't actually change the default version to |
This should bump the version to 5.0.1 and add the AppVersion to the charts.yaml |
@@ -83,6 +83,14 @@ spec: | |||
resources: | |||
{{ toYaml .Values.server.resources | indent 12 }} | |||
volumeMounts: | |||
{{- if .Values.provisioningDatasourcesFiles }} | |||
- name: provisioning-volume | |||
mountPath: {{ default "/var/lib/grafana/provisioning" .Values.server.provisioningLocalPath }}/datasources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured this is common practice in the chart. So, let's leave it for now. Would be cool to get that fixed in a separate PR.
@BugRoger could you fix the linting issues from the circleci build |
@BugRoger are you still working on this, if not I can help |
In my opinion is better to bump the minor version and remove at least the support to configure datasources using the Job, it is a hack that is difficult to maintain and not needed anymore. In general the dashboards Job will also not be needed but I think is handy to have the functionality to import remote dashboards. About bumping the minor version (or major) of the Chart, Grafana is not a project that has Long Term Support releases so keeping a Chart that is compatible with version 4.6.x and another compatible with >= 5 is not a big issue I think, eventually the Chart versions compatible with Grafana <= 4 will not be updated anymore and this will happen sooner than later. I want to use this Chart on the kube_prometheus "meta Chart" in prometheus-operator/prometheus-operator#1127, they are maintaining what is basically a copy of the stable Chart but adding grafana-watcher that essentially serves the same purpose as the Jobs here, both cases are hacks that with Grafana >= 5 are not required. |
Fixed the linter nitpicks. Bumped the version. Rebased on master. |
Any way to move this forward? |
Please update to the newest Grafana 5.0.4 Docker image as the older images don't work with Kubernetes 1.7.14, 1.8.9, or 1.9.4. This would probably also fix the build. |
9f99687
to
fc91d68
Compare
Rebased. Updated Image to 5.0.4. Added |
@BugRoger, sadly again conflicting files. I think this should be coordinated with someone that can merge, do the fix and immediately apply it. I'm waiting for this PR to be merged to work on the integration in https://github.com/coreos/kube-prometheus |
The same issue on 1.9.6-gke.0 |
How does this compare to #4541 ? |
please check out #4713 before merging. |
a856b34
to
baa8cfc
Compare
It seems i can't fix this. There's a deadlock between the different checks. The linter requires me to set the version to version in I can either resolve the conflict or fix the version. |
master is already at 0.8.5. You need to rebase and bump it to 0.8.6 or 0.9.0 |
Ah, rebased and bumped the version again.... |
/hold |
I'm inclined to close this in favor of #4713. |
@unguiculus if #4713 is merged it would make this PR no longer needed since #4713 is such a large overhaul and simplification. I have not tested #4713, but the changes themselves are heading in a good direction. |
This PR extends the
stable/grafana
chart to allow for outside configuration of provisioners.With Grafana 5 it will be possible to manage datasources and dashboards using provisioners. Adding a provisioner is done by adding one or more yaml configuration files in the
provisioning/datasources
andprovisioning/dashboards
directory. See also: http://docs.grafana.org/administration/provisioning/For datasources the file can contain a list of datasources that will be added or updated during start-up. If the datasource already exists, Grafana will update it to match the configuration file.
For dashboards the files contain the configuration for provisioning from external resources. It currently only support reading dashboards from file but more provisioners are in the works.
This functionality partly clashes with the jobs provided by this Helm chart. In order to support both Grafana 4/5 in the same chart, I think, it is a sensible approach to allow for both provisioning mechanisms. In the absence of more sophisticated provisioners (that allow the decoupling from Helm and dashboards) it is anyway required to load the dashboard from the filesystem and inject it using the existing mechanism.