Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: module for vending of routetable #428

Open
tobiasehlert opened this issue Nov 29, 2024 · 2 comments
Open

feat: module for vending of routetable #428

tobiasehlert opened this issue Nov 29, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@tobiasehlert
Copy link

  • 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

Is your feature request related to an issue?
No

We are currently vending our subscriptions and that includes a rg, vnet and a routetable, but that I've built as a separate component using the azapi_resource resource. But I think that from a platform team perspective the routetable resource is as close to the vnet as it can be and should not be something that should differ from any other vending-component.

Describe the solution you'd like

Have a separate module that I can vendor the routetable directly with the Azure/lz-vending/azurerm//modules/virtualnetwork module (or a separate one).

Additional context

This is how I've solved it as of today (don't have the locals and data sources included).

resource "azapi_resource" "lz_vending_routetable" {
  for_each = { for k, v in local.all_subscriptions : k => v if v.vnet_enabled == true }

  type      = "Microsoft.Network/routeTables@2024-01-01"
  name      = each.value.routetable_name
  parent_id = "/subscriptions/${each.key}/resourceGroups/${each.value.rg_name}"

  location = var.landing_zone.root_location

  body = {
    properties = {
      disableBgpRoutePropagation = true
      routes = [
        { name = each.value.vnet_name
          properties = {
            addressPrefix = each.value.vnet_address_space
            nextHopType   = "VnetLocal"
        } },
        { name = "our-alz-fw-${var.landing_zone.root_location}"
          properties = {
            addressPrefix = "${data.azurerm_public_ip.our-alz-fw-public-ip[var.landing_zone.root_location].ip_address}/32"
            nextHopType   = "Internet"
        } },
        { name = "default"
          properties = {
            addressPrefix    = "0.0.0.0/0"
            nextHopType      = "VirtualAppliance"
            nextHopIpAddress = "${one(data.azurerm_firewall.our-alz-fw-private-ip[var.landing_zone.root_location].ip_configuration).private_ip_address}"
        } },
      ]
    }
  }

  tags = local.default_tags

  depends_on = [
    module.enterprise_scale.azurerm_virtual_network,
    module.lz_vending_vnet,
  ]
}

A side note as well, we do have hub_peering_enabled = true and hub_peering_use_remote_gateways = false in terms what we have under the var.virtual_networks of virtualnetwork-module.

@tobiasehlert
Copy link
Author

@matt-FFFFFF, what you think about this? Considering creating a PR for this is if you see some value in it :)

@matt-FFFFFF
Copy link
Member

Hey,

Thanks for raising. I think that this is a valid ask, we will add it to the backlog but would also love to receive a PR.

We intend to revamp this module to use azapi 2 in the new year so I was holding off any feature requests until then. However if you want to raise one against the as-is then I'd be happy to review! #RR

@matt-FFFFFF matt-FFFFFF self-assigned this Dec 10, 2024
@matt-FFFFFF matt-FFFFFF added the enhancement New feature or request label Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants