terraform-ibm-modules/terraform-ibm-landing-zone-vpc

Update delegated resolver support and examples

vburckhardt opened this issue · 4 comments

vburckhardt commented

Description

The terraform provider limitations mentioned in the README at https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vpc/tree/main/examples/hub-spoke-delegated-resolver are being resolved from version 1.61 of the provider (currently in preview at 1.61.0-beta0 ) . This ticket covers the effort to update the module and example to use the re-designed feature in the provider.

ocofaigh commented

1.61.0 is out now

rajatagarwal-ibm commented

Context:

  • Current process: Currently we have 2 steps terraform apply process for hub and spoke delegated type VPC resolver. In the first apply it creates Hub VPC and Spoke VPC and before the second apply we set update_resolver_type to true (default: false) and execute the second apply, it changes Spoke VPC resolver from “system” to “delegated”
  • Expectations: With the recent IBM provider 1.61.0 update it should be done in the single terraform apply and we should get rid of the update_resolver_type variable.
  • Issues:
    1. Current design: Currently, the root module has one ibm_is_vpc resource which creates both Hub and Spoke VPCs. But with the change in the provider code, now Spoke VPC should have a depends_on on Hub VPCs custom resolver, which we cannot achieve with just one VPC resource.
  • Potential solutions:
    1. Create 2 ibm_is_vpc resources: One solution I came up with was to have 2 VPC resources in the root module, but then it has got “circular dependency” as we are creating hub VPC, custom resolver and spoke VPC on a conditional basis.
    2. Separate hub and spoke vpc submodule: Another solution is that we can create a hub and spoke VPC submodule, but we are not using the root SLZ VPC module to create VPCs, although we are using the root module for subnets creation.
      • Although it doesn't create a "delegated" resolver type as well in the single terraform apply. In the first apply it creates both Hub and Spoke VPCs but the Spoke VPC has a "system" custom resolver type. When I try to do terraform apply without making any changes, then it tries to change the resolver type from "system" to "delegated" but throws the following error:
image 
 [ERROR] Error Updating VPC : Delegated VPC is not configured with a custom resolver
rajatagarwal-ibm commented

I created a POC to test the feature, the apply works fine but when I destroy, it fails with the following error.

Error: [ERROR] Error updating the custom resolver to disable before deleting Not allowed to disable custom resolver on hub VPC which has DNS resolution bindings.:{

We already knew about the limitation when we were running tf apply twice. See this:

In order to perform a successful destroy, please set to the resolver to "system" in the spoke VPC through the UI before issuing the terraform destroy - see https://cloud.ibm.com/docs/vpc?topic=vpc-hub-spoke-configure-dns-resolver&interface=ui

https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vpc/tree/main/examples/hub-spoke-delegated-resolver

toddgiguere commented

While updating the examples we should also investigate a new requirement for auth policy: #757