Terraform: Data source to retrieve the name of the current region

[Lasering]

Feature request

It would be nice to be able to "read" variables from providers. The example below shows a clear and useful use case: the dns name is being created using the openstack region in which the servers are being launched.

Another example would be to set the configs for Consul cloud auto join.

provider "openstack" {  
  # All the variables will be set from the OS_ environment variables.
}

resource "openstack_compute_instance_v2" "servers" {
  # Omitted for clarity
}

resource "openstack_dns_recordset_v2" "server-ipv6" {
  zone_id = "${data.openstack_dns_zone_v2.default.id}"
  name    = "${var.environment}.${provider.openstack.region}.${local.domain}."
  ttl     = 60
  type    = "AAAA"
  records = ["${openstack_compute_instance_v2.servers.*.access_ip_v6}"]
}

[mtarnovan]

This would be especially useful when using modules. Otherwise you also need to pass in the variables used to configure the provider as module vars, resulting in lots of duplication.

[apparentlymart]

Hi @Lasering!

The usual pattern for doing this today is for the provider to offer a data source that exposes the desired information, rather than exposing it directly on the provider. While this does require more configuration, it avoids introducing a new concept that users would need to learn and understand.

For example, in the AWS provider this use-case is addressed by the aws_region data source.

For now, it's more practical to introduce similar data sources in other providers. With that in mind, I'm going to recast this issue as a feature request for the OpenStack provider to have an openstack_region data source.

We may revisit the more general suggestion in the long term, but for now the data source approach seems to be working without any specialized support from Terraform Core, and so we're planning to stick with this as the suggested pattern for the foreseeable future.

[hashibot[bot]]

This issue has been automatically migrated to terraform-providers/terraform-provider-openstack#247 because it looks like an issue with that provider. If you believe this is _not_ an issue with the provider, please reply to terraform-providers/terraform-provider-openstack#247.

[Lasering]

Hi @apparentlymart,

I understand why do it via a data source declared externally from the provider. However what I wanted to get at is in fact the more general feature.

Let me give another example where this would be useful:

provider "chef" {
  server_url = "https://api.chef.io/organizations/example/"
  client_name  = "terraform"
  key_material = "${file("chef-terraform.pem")}"
}

# Openstack is just an example, could be AWS
resource "openstack_compute_instance_v2" "basic" {
  name            = "basic"
  image_id        = "ad091b52-742f-469e-8f3c-fd81cadf0743"
  flavor_id       = "3"
  key_pair        = "my_key_pair_name"
  security_groups = ["default"]

  provisioner "chef" {
    environment     = "_default"
    run_list        = ["cookbook::recipe"]
    node_name       = "webserver1"
    server_url      = "${provider.chef.server_url}"
    recreate_client = true
    user_name       = "${provider.chef.client_name}"
    user_key        = "${provider.chef.key_material}"
  }
}

More specifically this would allow me to refactor the configurations for chef in a single and concise location.

The way I see it having the data source "internally" isn't really adding new concepts, its just like using the self.ATTRIBUTE syntax that is allowed within provisioners.

If every entity (resource, provider, data source, etc) provided an internal data source it would make the memory model of how to use Terraform simpler since one could assume every configuration would also be exported. This would allow refactoring Terraform recipes much more easily. What I'm suggesting in this issue is just a cut-down version of this idea.

[hashibot[bot]]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.