grafana
Support for `org_id` key inside the `grafana_data_source` block
We manage several organizations with different org_id within Grafana and we'd like to deploy Grafana Loki and Prometheus data sources for each organization.
The way it is described here does not suit us because it requires to create a separate provider "grafana" alias for each organization since Terraform does not yet support for_each and count to allow loops in the provider block. You can refer to this issue.
In addition, there is no field org_id inside the resource "grafana_data_source" block while it is present in the Grafana data source yaml itself.
Are there any workarounds regarding this issue?
You can create your grafana provider (and datasource) in a module and for_each over the module
@julienduchesne I'm not sure if this works. When I create a provider inside a module, I need something like this to iterate over its aliases:
provider "grafana" {
alias = var.tenant_name
url = var.grafana_url
org_id = var.tenant_org_id
}
What I receive, is an error:
Error: Invalid provider configuration alias
An alias must be a valid name. A name must start with a letter or underscore
and may contain only letters, digits, underscores, and dashes.
Error: Variables not allowed
on modules/grafana_data_source/main.tf line 25, in provider "grafana":
25: alias = var.tenant_name
Variables may not be used here.
terraform v0.14.10
How can I iterate over a bunch of different aliases if it does not allow me to indicate a variable next to alias?
@julienduchesne Well, my situation is the following: I need to leave the main grafana provider block at the terraform root level for compatibility with other code and have different org_id's inside a module as you suggested. It seems that it is only possible to use org_id inside a provider block. So, I tried this in the module (without an alias, because it does not allow variables):
provider "grafana" {
url = var.grafana_url
org_id = var.tenant_org_id
}
Got an error:
Error: Module does not support for_each
on main.tf line 228, in module "grafana_data_source":
228: for_each = var.tenant_map
Module "grafana_data_source" cannot be used with for_each because it contains
a nested provider configuration for "grafana", at
modules/grafana_data_source/main.tf:23,10-19.
This module can be made compatible with for_each by changing it to receive all
of its provider configurations from the calling module, by using the
"providers" argument in the calling module block.
As the answer suggests here, I need to use aliases, but, again, I cannot iterate over them.
Ah, that is an annoying limitation from Terraform. Let's keep this issue open then. However, it's not an easy fix and I'm not aware of any workarounds unfortunately
@YevheniiPokhvalii do you find a solution for this? (include terraform alternatives?)
One thing that is possible (outside of Terraform) is to template your .tf files with a tool like jinja2 or gomplate. It allows you to define providers in a loop.
An annoying thing about this is that, to delete resources, you have to keep the "provider", destroy the resources and then remove it. If you just remove the item from the loop (losing the "provider" and the resources), Terraform will not be able to delete anything and crash
I had the same idea and come to the same problem. From my point of view, in the current state, the terraform does not fit here. Since there is no solution for dynamic providers.
this feels like a really weird scenario, given that you can create an org via the provider. You could easily see a scenario where I would want to define an organization and its data sources in the same module.
Instead it seems like I need to create them in separate modules just to work around this?
Why you can not to this in one module? The additional provider can depends on the org resource.
https://github.com/grafana/terraform-provider-grafana/blob/master/docs/index.md#creating-a-grafana-organization-provider-on-premise
Even though this issue is older, I'll close it in favor of https://github.com/grafana/terraform-provider-grafana/issues/747, since that newer one is more general. I think extracting org_id is a good idea. It's a fair bit of work but it'll probably happen eventually