You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently trying to come up with a GitOps style workflow for managing Grafana Dashboards for our project. We have a single Azure Managed Grafana instance serving all our environments (the usual DEV/QA/STAGING/PROD x multiple regions).
On the deployment side, I hope use GRAFANA_TOKEN=... grr apply ... with GRAFANA_TOKEN stored as a CI secret. Of course, ideally our DevOps would rather see something based on Federated Identity but apparently this is not yet supported in Grafana, so a solution base on SAT is acceptable. I am aware of Grafana Terraform Provider and of Grafana Operator. However with the operator there is a certain misalignment due to the fact that we want to have Dashboards integrating data from multiple environments. And Terraform opens another can of fat worms starting from requiring a state storage. So, Grizzly seems like the best fit, esp. if #557 is resolved (if not, this could be implemented separately).
My main stumbling block is that I do not understand how to devise a practical workflow considering that developers do not have write permissions to target Grafana folder. A sandbox folder to which developers will have write permissions may be created if necessary (frankly, I am still unclear on how Grizzly does its magic). Also, ideally developers should not need to deal with any tokens. The flow should work for both generated (e.g. using Grafana Foundation SDK) and visually edited dashboards. A nice to have feature would be a possibility for CI builds for PR to publish all the Dashboards in a subfolder of some "CI PR builds" folder (a PR comment with a link to that folder would be automatically added) so that reviewers of a PR would be able to try it out.
I suspect that due to the lack of support of SSO (#451) my best current practical approach would be using a SAT that would have write permissions to a sandbox folder. The SAT would be stored in Azure KV directly, or in sops. Ugly but doable.
Please share your thoughts. Are there any obstacles with the described approach? Could it be done better with less moving parts?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am currently trying to come up with a GitOps style workflow for managing Grafana Dashboards for our project. We have a single Azure Managed Grafana instance serving all our environments (the usual DEV/QA/STAGING/PROD x multiple regions).
On the deployment side, I hope use
GRAFANA_TOKEN=... grr apply ...withGRAFANA_TOKENstored as a CI secret. Of course, ideally our DevOps would rather see something based on Federated Identity but apparently this is not yet supported in Grafana, so a solution base on SAT is acceptable. I am aware of Grafana Terraform Provider and of Grafana Operator. However with the operator there is a certain misalignment due to the fact that we want to have Dashboards integrating data from multiple environments. And Terraform opens another can of fat worms starting from requiring a state storage. So, Grizzly seems like the best fit, esp. if #557 is resolved (if not, this could be implemented separately).My main stumbling block is that I do not understand how to devise a practical workflow considering that developers do not have write permissions to target Grafana folder. A sandbox folder to which developers will have write permissions may be created if necessary (frankly, I am still unclear on how Grizzly does its magic). Also, ideally developers should not need to deal with any tokens. The flow should work for both generated (e.g. using Grafana Foundation SDK) and visually edited dashboards. A nice to have feature would be a possibility for CI builds for PR to publish all the Dashboards in a subfolder of some "CI PR builds" folder (a PR comment with a link to that folder would be automatically added) so that reviewers of a PR would be able to try it out.
I suspect that due to the lack of support of SSO (#451) my best current practical approach would be using a SAT that would have write permissions to a sandbox folder. The SAT would be stored in Azure KV directly, or in sops. Ugly but doable.
Please share your thoughts. Are there any obstacles with the described approach? Could it be done better with less moving parts?
Related:
#557
#451
#258
grafana/grafana#16424
grafana/grafana#53567
Beta Was this translation helpful? Give feedback.
All reactions