oci_dns_resolver and DNS resolver endpoint dependency issue

[MadalinaPatrichi]

https://github.com/oracle/terraform-provider-oci/blob/e1564768dcbf23ebfd3c3c215e78c5fca3db024a/examples/dns/private/resolver/dns_resolver.tf#L9-L14

These instructions are incorrect, users should not be recommended to run the application of their Terraform code twice and modify code in-between changes.

There is a method of addressing this issue with the use of a dns_resolver_association data provider in order to pass in the dns_resolver_id and this will circumvent the dependency issue: https://registry.terraform.io/providers/oracle/oci/latest/docs/data-sources/core_vcn_dns_resolver_association

Is the implementation of the Terraform providers broken though? Deleting the resources defined here cannot be deleted via Terraform in a single run because of the dependency issues

[daniloulbrecht]

This issue still persists even in newer versions of oci provider, is a well known and old issue. Here we are very disappointed that the only way to create a new VCN with all components is first create the VCN itself alone with --target option and after that create other components including dns resolvers, because they use the data source collected from VCN information (dns resolver association). The required DNS resolver association should be an attribute exported in the VCN creation, this way it will be not necessary get this information using data source.

[ravinitp]

affected_resources=oci_dns_resolver

[dsab123]

Hello, has there been any update on this ticket?

[paolajuarezgomez]

Hi, any update ?

[daulbrecht]

Hello everyone. Reviewing this case, I believe a final solution on the provider code was never released. Just to contribute, here the way I found to overcome this problem on your code using terraform tricks and running just once.

// Block of code to create your VCN

resource "oci_core_vcn" "vcnprod" { cidr_blocks = [var.cidr_block_vcn_prod] compartment_id = var.prod_network_compartment_id display_name = "oci-sp-vcn-${var.team_or_project_name}-prod" dns_label = "ocispprd${var.team_or_project_name}" defined_tags = var.team_tag }

// Create a block of code of resource "time_sleep" that will run immediately after the creation of your VCN, using depends_on argument.

resource "time_sleep" "wait_vcn_and_resolver_up" { create_duration = "120s"

depends_on = [oci_core_vcn.vcnprod] }

// The trick is that 120s is enough to VCN and VCN DNS resolver to be UP

// Collect oci_core_vcn_dns_resolver_association with a data resource to use later to create your dns endpoint, notice again the use of depends_on argument, waiting resource time_sleep (120s).

data "oci_core_vcn_dns_resolver_association" "dnsresolverprod" { depends_on = [time_sleep.wait_vcn_and_resolver_up] vcn_id = oci_core_vcn.vcnprod.id }

//oci_core_vcn_dns_resolver_association will export dns_resolver_id attribute.

// Finally the block code to create your endpoint, again using a depends_on argument

resource "oci_dns_resolver_endpoint" "endpointforwardingprod01" { depends_on = [data.oci_core_vcn_dns_resolver_association.dnsresolverprod] is_listening = false is_forwarding = true name = "DNS_FORWARD_01" resolver_id = data.oci_core_vcn_dns_resolver_association.dnsresolverprod.dns_resolver_id subnet_id = oci_core_subnet.snetprodapp.id scope = "PRIVATE" forwarding_address = local.dnsforwardip }

This way you can run your code once, without "apply --target" parameter or the need to comment DNS resolver blocks before vcn creation. Hope this helps someone

[dsab123]

Very nice! Our team has moved on to work in other clouds but we'll reference this and update this post when that work comes back again.