Support for creating a route rule using a separate resource

[ITD27M01]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

It is a must have resource which is not implemented for some reason. For such tasks as customer VPN connection or VCN local peering we need to dynamically update the existing route table by new routes.

The base use case is ISV Architecture [1], where Customers are connecting dynamically. There is needed automation for such attaching to the management compartment.

I'm developing a terraform module for peering establishment with Management Compartment - it should create the LPGs and update the Management Compartmens route table for proper communication.

New or Affected Resource(s)

oci_core_route

Potential Terraform Configuration

resource "oci_core_route" "ipsec_route" {
  route_table_id = var.route_table_id

  network_entity_id = oci_core_drg.dynamic_router_gateway.id

  description      = "Why I cannot set routes in dedicated resource?"
  destination_type = "CIDR_BLOCK"
  destination      = var.cpe_static_routes[0]

  freeform_tags = merge(local.default_tags, var.tags)
}

References

[1] https://www.ateam-oracle.com/isv-architecture [2] https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/localVCNpeering.htm [3] https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/overviewIPsec.htm

The example for AWS provider: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route_table https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/route

[varmax2511]

Hi @ITD27M01 -- thanks for reaching out. Can you please explain the use case you are trying to solve via a new resource for route rules? We also support https://registry.terraform.io/providers/hashicorp/oci/latest/docs/resources/core_route_table_attachment for attaching route tables to subnets

[ITD27M01]

Hi @varmax2511

The main use case is ISV Architecture [1] where Customers are connecting dynamically and there is needed the automation for such attaching to the management compartment:

I'm developing a terraform module for peering establishment with Management Compartment - it should create the LPGs and update the Management Compartmens route table for proper communication.

Attaching route tables to subnets doesn't help because there only one route table for number of underlying customer compartments. And this one route table need to be updated.

[1] https://www.ateam-oracle.com/isv-architecture

[hyder]

This would also support reusability of modules e.g. my network module is developed independently and I would like to reuse it. However, the route table and routing rules e.g. for NAT gateway has already been created. I now need to update the existing route table with additional set of rules. It would be great if we are able to specify the route rules separately from the routing table itself. In doing so, all we then need to do is update the list of route rules for this route table.

[ITD27M01]

Hi @hyder

Let's discuss it to help engineers make decision.

The first problem is the route table rule doesn't exist in API OCI as a separate resource. To update route rules you should POST to route table object [1] with a list of rules. Of course, even in this case, there is a way to analyze the "state" and ensure idempotence.

It would be nice if route tables and route rules were located in different database tables and had relationships, so there would be a separated API object which we could manage by Terraform resource.

The next point is Terraform HCL language capabilities for dynamic blocks [2]. In this way you need to reconstruct your life and rethink how you connect your modules (read about it after an example).

You can manage such rules throughout dynamic block:

#vars.yaml
routes_variable:
  - name: Route rule for task1
     network_entity_id: OCID
     type: 'CIDR_BLOCK'
     destination: '192.168.0.0/24'
  - name: Route rule for task2
     network_entity_id: some another OCID
     type: 'CIDR_BLOCK'
     destination: '192.168.1.0/24'
  
#route_table.tf
resource "oci_core_route_table" "test_route_table" {
    #Required
    compartment_id = var.compartment_id
    vcn_id = oci_core_vcn.test_vcn.id

     dynamic "route_rules" {
         for_each = var.routes_variable
         content {
             network_entity_id = route_rules.value["network_entity_id"]
             cidr_block = route_rules.value["cidr_block"]
             destination = route_rules.value["destination"]
             destination_type = route_rules.value["destination_type"]
         }
     }
}

So, in the case the routes_variable generated on the fly during Terrafrom run you can pass such data to dynamic block.

There are two problems:

1. The sequence of run - module WHERE the routing table is placed runs first and module FROM which data is accessible runs second.
2. Of course, you can rearrange the code and create network things first in one run. In this way you need to rethink how you managed infrastructure previously. How you're doing it now:

module_for_main_infra:
   compartment:
   network:
   dbinstance:
module_for_project1:
   compartment:
   network:
   dbinstance:
module_for_project2:
   compartment:
   network:
   dbinstance:

How you need to change it:

base_module_for_whole_infra:
   compartments:
      compartmen1:
      compartmen1:
   networks:
      network_for_compartment1:
      network_for_compartment2:
   route_table:
     collect_info_from_previous:
module_for_project1:
   dbinstance:
module_for_project2:
   dbinstance:

Currently it looks like a pain for me.

[1] https://docs.oracle.com/en-us/iaas/api/#/en/iaas/20160918/RouteTable/UpdateRouteTable [2] https://www.terraform.io/docs/configuration/expressions/dynamic-blocks.html

[varmax2511]

thanks, we will work on prioritizing this request and investigate on what can be done

[ITD27M01]

Hi, some workaround for this: https://pypi.org/project/ortu/

resource "null_resource" "right_route_table_update" {
  triggers = {
    right_lpg = oci_core_local_peering_gateway.right_lpg.id
  }

  provisioner "local-exec" {
    command = "ortu --rt-ocid ${data.oci_core_route_tables.right_route_table.route_tables[0].id} --cidr ${data.oci_core_vcn.left_vcn.cidr_block} --ne-ocid ${oci_core_local_peering_gateway.right_lpg.id}"
  }
}

resource "null_resource" "left_route_table_update" {
  triggers = {
    left_lpg = oci_core_local_peering_gateway.left_lpg.id
  }

  provisioner "local-exec" {
    command = "ortu --rt-ocid ${data.oci_core_route_tables.left_route_table.route_tables[0].id} --cidr ${data.oci_core_vcn.right_vcn.cidr_block} --ne-ocid ${oci_core_local_peering_gateway.left_lpg.id}"
  }
}

[dralquinta]

Hi,

Was this somehow picked for development? I also see this feature highly desirable. I've checked ortu workaround and as I'm sure it'll work just fine, it starts complicating things up as it'll necessarily needs a pip module and then local execution for something that should be simple to do just like AWS does it in the following very old sample: https://jamesd3142.wordpress.com/2018/05/02/how-to-import-a-vpc-route-table-to-terraform-state/

In here, you just import the ID of the route table and then use it any way you like. Issue with OCI Route Table is that there is no real way to import the OCID for later manipulation.

Is this somehow prioritized or scheduled for analysis/fix?

[hyder]

@dralquinta I've escalated it internally

[ITD27M01]

@dralquinta I can confirm that ortu is just workaround and we have to live with pip install in our automation.

As I said in another issue, the root cause of such problems is OCI API architecture where external dependent objects are managed inside one API update request: https://docs.oracle.com/en-us/iaas/api/#/en/iaas/20160918/RouteTable/UpdateRouteTable

The route rules are part of UpdateRouteTableDetails and cannot be managed as a separate resource.

The same issue is for DNS resolver rules: https://docs.oracle.com/en-us/iaas/api/#/en/dns/20180115/Resolver/UpdateResolver

So, we have to write python scripts to get around this.

[Eric-Jckson]

I'm running into a similar that would be able to benefit from a route route resource. Is this request still being tracked internally?

[ravinitp]

We are very sorry that we couldn't respond to each and every issue reported on GitHub. Although we have refined the process to prioritize customer issues on GitHub, since this issue was reported a while ago, there is a good chance it may have been fixed in the latest version of Terraform Provider OCI. If you are still experiencing this issue, please create a new issue and label it as Bug.

[DevOpsFu]

Why create a new issue when everything we need to know is already in this one? I started following this issue recently because I came up against exactly the same problem.

There is definitely no separate route rule resource type for the OCI Core Route table resource, and this issue is still required.

@ravinitp can you not just reopen this issue and mark it as active?