CODEWITHSUNDEEP
terraformterraform-provider-aws
Tennis Smith
Tennis Smith

Reputation: 491

Provider requires dynamic output of resource: what to do?

I am successfully creating a vmc_sddc resource. One of the attributes returned from that is "nsxt_reverse_proxy_url".

I need to use the "nsxt_reverse_proxy_url" value for another provider's (nsxt) input.

Unfortunately, Terraform rejects this construct saying the "host name must be provided". In other words, the dynamic value is not accepted as input.

Question: Is there any way to use the dynamically-created value from a resource as input to another provider?

Here is the code:

resource "vmc_sddc" "harpoon_sddc" {
  sddc_name           = var.sddc_name
  vpc_cidr            = var.vpc_cidr
  num_host            = 1
  provider_type       = "AWS"
  region              = data.vmc_customer_subnets.my_subnets.region
  vxlan_subnet        = var.vxlan_subnet
  delay_account_link  = false
  skip_creating_vxlan = false
  sso_domain          = "vmc.local"
  deployment_type     = "SingleAZ"
  sddc_type           = "1NODE"
}

provider "nsxt" {
  host                 = vmc_sddc.harpoon_sddc.nsxt_reverse_proxy_url // DOES NOT WORK
  vmc_token            = var.api_token
  allow_unverified_ssl = true
  enforcement_point    = "vmc-enforcementpoint"
}

Here is the error message from Terraform:

╷
│ Error: host must be provided
│ 
│   with provider["registry.terraform.io/vmware/nsxt"],
│   on main.tf line 55, in provider "nsxt":
│   55: provider "nsxt" {
│

Thank you

Upvotes: 1

Views: 516

Answers (1)

Martin Atkins
Martin Atkins

Reputation: 74279

As you've found, some providers cannot handle unknown values as part of their configuration during planning, and so it doesn't work to dynamically configure them based on objects being created in the same run in the way you tried.

In situations like this, there are two main options:

  • On your first run you can use terraform apply -target=vmc_sddc.harpoon_sddc to ask Terraform to focus only on the objects needed to create that one object, excluding anything related to the nsxt provider. Once that apply completes successfully you can then run terraform apply as normal and Terraform will already know the value of vmc_sddc.harpoon_sddc.nsxt_reverse_proxy_url so the provider configuration can succeed.

    This is typically the best choice for a long-lived configuration that you don't expect to be recreating often, since you can just do this one-off extra step once during initial creation and then use Terraform as normal after that, as long as you never need to recreate vmc_sddc.harpoon_sddc.

  • You can split the configuration into two separate configurations handling the different layers. The first layer would be responsible for the "vmc" level of abstraction, allowing you to terraform apply that in isolation, and then the second configuration would be responsible for the "nsxt" level of abstraction building on top, which you can run terraform apply on once you've got the first configuration running.

    This is a variant of the first option where the separation between the first and second steps is explicit in the configuration structure itself, which means that you don't need to add any extra options when you run Terraform but you do now need to manage two configurations. This approach is therefore better than the first only if you will be routinely destroying and re-creating these objects, so that you can make it explicit in the code that this is a two-step process.

In principle some providers can be designed to tolerate unknown values as input and do offline planning in that case, but it isn't technically possible for all providers because sometimes there really isn't any way to create a meaningful plan without connecting to the remote system to ask it questions. I'm not familiar with this provider so I don't know if it's requiring a hostname for a strong technical reason or just because the provider developers didn't consider the possibility that you might use it in this way, and so if your knowledge of nsxt leads you to think that it might be possible in principle for it to do offline planning then a third option would be to ask the developers if it would be feasible to defer connecting to the given host until the apply phase, in which case you wouldn't need to do any extra steps like the above.

Upvotes: 1

Related Questions