Create helm chart for agones dashboards

[zifter]

Is your feature request related to a problem? Please describe. I would like to use provided agones dashboards out of box. At that moment I have to create resources directly, without any possibility to customize namespace, grafana discovery label, labels and etc.

Describe the solution you'd like I suggest creating helm chart agones-dashboards, which will allow installing dashboards as helm release with possibility to customize some properties. This chart must be published together with agones helm chart.

Describe alternatives you've considered

1. Leave it as is it;
2. Use alternative package manager (instead of helm).

Additional context I created an example of chart, how it possibly will look like. Installation is pretty simple:

helm install agones-dashboards zifter/agones-dashboards --namespace monitoring

And also, it will be easy to use/to change dashboards json sources, because they will be stored as is it (without in-placing in yaml file): example of chart

[roberthbailey]

That sounds like a good idea. I've always installed the dashboards from yaml but I haven't needed to customize them. As part of the proposal, could you create a table (like we have at https://agones.dev/site/docs/installation/install-agones/helm/#configuration) explaining what the configuration parameters are that you would want to customize? I think that would help us understand the use cases better.

And also, it will be easy to use/to change dashboards json sources, because they will be stored as is

I'm not sure I fully understand this point. If the json source is stored in the helm chart, how will that make them easier to customize? Wouldn't you just get whatever version is in the chart? Or are you saying that you could create your own chart with customized versions of those files?

[markmandel]

A follow up question on this one:

I always assumed this samples would be used as more of an example/starting point to dashboards, and people would manually merge and/or tweak them into their own game specific dashboard scenarios.

That assumption could be way off base, so would definitely love to learn more about how you are planning your monitoring dashboards, and how you would ideally like to see all the integrations working.

[zifter]

Thank you for reply!

A follow up question on this one:

I always assumed this samples would be used as more of an example/starting point to dashboards, and people would manually merge and/or tweak them into their own game specific dashboard scenarios.

That assumption could be way off base, so would definitely love to learn more about how you are planning your monitoring dashboards, and how you would ideally like to see all the integrations working.

Let me try to explain my working setup and some use cases of agones dashboard. What I have: I have 3 different grafana application, deployed in different kubernetes clusters - production cluster, backoffice cluster and local cluster with dev environment. Local cluster can be fully deleted and created from the start.

So, use cases:

1. I would like to see agones dashboards to be ready to use after local dev cluster created and installation of all necessary charts. Installing them as Kubernetes manifest is really helpful in this case. This yamls are stored in git repository and are installing during dev cluster creation. Of course, it's pretty simple to import them via grafana UI manually and start using them, but sometimes it's inconvenient and takes a lot of time, especially when you have a hundred of other dashboards.

2. I would like to change dashboard. And it must be done in each grafana. In production cluster, I can't do that because of access restriction. In Backoffice cluster, it can be done easily. In local dev cluster, it's easy to do. But it's necessary to commit changes. I like to work with dashboards via git repo in a project, because it's become obligatory to pass code review (of course, it's better review dashboard in grafana, not a json file =). So IaaC approach for dashboards. Of course, there are lots of other ways to do that, but describe my own use case.

So, how I see the process I have helm chart agones dashboards in git repository. Helm chart is easy to operate instead of raw manifests. When I need to change something in dashboards, I run local dev cluster, do changes in dashboards, save json files, create pr, pass review and then merge changes into master. As a result, changes will be delivered from master branch to production and backoffice clusters automatically. Changes in local dev cluster can be applied in the same way, just calling helm upgrade.

Conclusion I would prefer to have dashboards which is provided with the application, and it's not necessary to modify them at all. Dashboards must cover all basic cases of monitoring application out of the box, because, basically, people are too lazy to understand and polish them after "starting point". So, it would be great that agones community will create well-prepared and universal dashboards for users.

Example of Agones Dashboards helm charts for 1.16.0 Example of Application helm chart with Dashboards out of the box

[zifter]

That sounds like a good idea. I've always installed the dashboards from yaml but I haven't needed to customize them. As part of the proposal, could you create a table (like we have at https://agones.dev/site/docs/installation/install-agones/helm/#configuration) explaining what the configuration parameters are that you would want to customize? I think that would help us understand the use cases better.

As for me, it's not necessary to customize dashboards at all. It's better to customize some "service variables", like

• helm chart release name
• namespace to install
• grafana discovery label
• target folder to place dashboards

As example, please look at these values.yaml file. It is 99% ready to use agones dashboards helm chart.

And also, it will be easy to use/to change dashboards json sources, because they will be stored as is

I'm not sure I fully understand this point. If the json source is stored in the helm chart, how will that make them easier to customize? Wouldn't you just get whatever version is in the chart? Or are you saying that you could create your own chart with customized versions of those files?

I mean, it's better to store dashboards as json files, please, look at this folder. It's an opposite way to store yaml files with included dashboard json as a part. In this case, it will be easy to use dashboards as a part of helm chart or just import json directly from grafana UI.

[markmandel]

As an extra thought - if we do make a helm chart, we should also export an install.yaml (like we do for Agones). Not everyone uses Helm, so we should have a basic install option as well.

[github-actions[bot]]

'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '

[github-actions[bot]]

This issue is marked as obsolete due to inactivity for last 60 days. To avoid issue getting closed in next 30 days, please add a comment or add 'awaiting-maintainer' label. Thank you for your contributions