-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stackdriver Dashboards #5124
Stackdriver Dashboards #5124
Comments
Once a dashboard has been created in the Cloud Console, dashboards.get can retrieve a JSON representation. If
Maybe a field IMO this would be easier than rewriting the dashboard configuration in HCL, although I couldn't find an existing resource that follows this pattern (google_bigquery_table's schema is similar). |
If we add import support, would that resolve your concerns? People often use Terraform in order to standardize the process for their teams to not use the console, ever, and so requiring creating one in the console first before exporting it to Terraform feels not great. |
How would the import workflow work? I haven't used it extensively, but the phrase "prior to running terraform import it is necessary to write manually a resource configuration block for the resource" would suggest I'd still have to write a complete configuration. While I also prefer to use Terraform instead of the console, in the case of creating/tweaking a graphical dashboard I would prefer edit-view-repeat to edit-apply-refresh-view-repeat. Of course, handwriting or editing the JSON would be similar editing the dashboard in Terraform config. My use case would require code review of edits to dashboards, restoring modified dashboards to a known state, and potentially installing the same dashboard to multiple projects. Caveat: I'm currently planning on doing this with Grafana instead, so it would be worth checking instead with the users that are actively using Stackdriver Dashboards and want to use Terraform for them. |
I agree that it would be worth getting opinions from Terraform users on this pattern, since it's super uncommon across providers. |
I have contacted three Terraform users who requested this feature. The two that responded prefer the UI+JSON workflow. How does affect the issue size/priority? I proposed the following workflows:
Response from developer advocate:
Response from GCP customer:
|
I would still prefer the Terraform-only workflow for 2 reasons:
|
Is the developer advocate a terraform user, or someone from the product side? Just want to get a sense of whether their opinion is coming from their expectations of how users use a product or whether it's because they actively are using it. Regardless, it probably makes sense to have the json ability, but it might make sense to also have a resource that allows for HCL, which makes it easier for our customers to use interpolation and also makes it easier for us to add plan-time checks (rather than just sending over a json blob and waiting for the API to tell us whether or not it's valid). |
I don't know, although looking at their comments again, I don't get the impression they're heavy user. |
@drigz As Stackdriver user I would strongly prefer HCL approach despite the fact I don't like HCL. Console UI-first approach is a bad idea:
|
@c2h5oh agree with you. I think the HCL approach does make sense. Note that in this approach, we can still download a JSON dashboard and |
After some discussion we've decided we might just take the json approach where you can download it from the console and paste it into the HCL. If we went with an HCL approach, this resource would be by far the largest with number of fields and the amount of nesting, the json approach allows us to implement this much faster so users can start using it. |
Hey all, sorry to keep going back and forth on this one. After talking to the Stackdriver team, it sounds like the question of which approach to go with is no longer set in stone, and we'd like to take some more time to think this through. As usual, if you have preferences that haven't yet been voiced (around the implementation specifically, not just that you want support for the resource), feel free to comment! In the meantime, I moved this back into the Near-Term Goals milestone since we'd like to start working on this soon, but can't actively work on it at the moment. |
If the JSON approach, what will be my options to impact the JSON content based on variables, etc. Would I need to build the whole JSON with string operations? |
You should be able to do it with |
then, please do whatever is faster, I really hate that I have to write shell scripts for this |
So, is anyone developing a new google provider to create stack driver dashboards using HCL terraform? |
I am quite new to gcp and terraform, it seems like google_monitoring_dashboard is till in development and has not yet released for integrating stackdriver dashboard in gcp using terraform. Is my understanding correct ? Or if I can use it and test it ? |
That's correct! The linked PR is currently out for review. If you wanted to try it out, you could check out https://github.com/modular-magician/terraform-provider-google-beta/tree/auto-pr-3490 and then build the provider on your own, but I'm not going to get into the details of how to do that here (basically, clone the modular-magician fork, check out the branch, and run Our documentation at https://www.terraform.io/docs/providers/google/index.html is up to date with what has been released, and you can also always take a look at the https://github.com/terraform-providers/terraform-provider-google/blob/master/CHANGELOG.md to know as well. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
Community Note
Description
https://cloud.google.com/monitoring/api/ref_v3/rest/v1/projects.dashboards
New or Affected Resource(s)
Potential Terraform Configuration
References
The text was updated successfully, but these errors were encountered: