Cleanup support for networks, subnets, routers, router interfaces

[claudia-lola]

Improves the definition for the above items to correctly model dependencies and more closely match the current Ansible stackhpc/openstack-config configuration.

Example config:

module "openstack" {
  source = "github.com/stackhpc/tofu-openstack-config?ref=network-support"
  projects = {
    "demo-project" = {
      compute_quota = {
      }
      network_quota = {
      }
      blockstorage_quota = {
      }
    }
  }

  networks = {
    "demo-network:demo-project" = { #tofu resource name
      name = "demo-network" #openstack network name
      project = "demo-project"

      subnets = {
        "demo-subnet:demo-project" = { #tofu resource name
          name = "demo-subnet" #openstack subnet name
          cidr = "10.0.0.0/24"
        }
      }
    }
  }

  routers = {
    "demo-router:demo-project"  = { #tofu resource name
      name = "demo-router" #openstack router name
      project = "demo-project"
      external_network = "demo-network:demo-project" #tofu resource name of network
      external_fixed_ips = [{
        subnet = "demo-subnet:demo-project" #tofu resource name of subnet
      }]
      interfaces = [
        { subnet = "demo-subnet:demo-project" } #tofu resource name of subnet
      ]
    }
  }

}

[sjpb]

As discussed elsewhere:

• PR description and title need work
• Resources which are nested in current ansible config should be nested, i.e. subnets -> networks, router interfaces -> router
• child resources (subnets/router interfaces) should have a composite key refering to their parent, so children of the same name can exist in different parents
• Networks are not a child of a project but MAY reference them. So being able to provide tenant ID (for networks in projects NOT controlled by this config) or project name (for networks in projects which ARE controlled by this config) is OK, but needs documenting. And the resource key NOT being based on the network name but being a user-defined unique key again makes sense in this context (as not child of projects) but again needs documenting.

[sjpb]

In PR comment:

  networks = {
    "demo-network:demo-project" #tofu resource name = {

should that be

  networks = {
    "demo-network:demo-project" = {  #tofu resource name 

and similar ...

[sjpb]

Last review said:

child resources (subnets/router interfaces) should have a composite key refering to their parent, so children of the same name can exist in different parents

But in PR comment:

...
subnets = [
        { 
          key = "demo-subnet:demo-project" #tofu resource name
          name = "demo-subnet" #openstack subnet name
          project = "demo-project"
        }
      ]

a) You're having to create this composite key yourself - I'd have expected it to have been created from the parent network key + the subnet name.
b) Why is project or tenant_id required - they're available from the parent network?

I'd have expected this example to look like:

  networks = {
    "demo-network:demo-project" = { # unique resource name 
      name = "demo-network" #openstack network name
      project = "demo-project"

      subnets = {
        "demo-subnet" = {} # openstack subnet name
      }
    }
  }

Edit: Hmm I see having the user-created unique key on the subnet does allow e.g. router interfaces to reference it. Maybe that's simpler to explain.

The point re. project/tenant ID stands, they cannot be different from the parent network. And so given the point elsewhere about not using the list idx in the key for idempotency, maybe it'd be better as

  networks = {
    "demo-network:demo-project" = { # unique resource name 
      name = "demo-network" #openstack network name
      project = "demo-project"

      subnets = {
        "demo-subnet:demo-project" = { # tofu resource name
           name = "demo-subnet" # openstack subnet name
      }
    }
  }

[sjpb]

So top-level:

1. Don't use idx as part of the resource name - it breaks idempotency if things in the list get reordered/moved. So e.g. I think instead of subnets being a list of maps where elements have a "key" parameter, just make it a map, keyed directly by that.
2. The PR first comment isn't valid HCL, there's comments inside {} which won't work, and the formatting is a bit wacky. Just copy it into a separate file and run tofu fmt on it until it stops complaining.
3. Where child resources can only take same values as their parent, you shouldn't need to respecify them. E.g. having to pass "project" to subnet when the parent "network" has it is not necessary/bad UX.
4. I can see that subnets do probably need a manually-specified unique key. Else it'll get hard to reference them from e.g. router interfaces.
5. Leaving the ability to specify e.g. subnet ids directly is neat - lets us e.g. specify router interfaces even when the subnet is not part of this config 👍
6. Where map variables include lists/maps, the type of that should be specified.

[sjpb]

Suggested change

	interfaces: Optional list -
	interfaces: Optional list of maps:

[sjpb]

If this is a list, is it "stable" if you e.g. have 3x interfaces and delete the 2nd? i.e. it only shows the deletion, not a delete/recreate for 3rd? I think it should be if you get the resource key correct, but be nice to have that confirmed