Open Stack

Hi,

When configuring TripleO deployments with nodes on routed ctlplane
networks we need to pass some per-network properties to the
NetworkConfig resource[1] in THT. We get the ``ControlPlaneIp``
property using get_attr, but the NIC configs need a couple of more
parameters[2], for example: ``ControlPlaneSubnetCidr``,
``ControlPlaneDefaultRoute`` and ``DnsServers``.

Since queens these templates are jinja templated, to generate things
from from network_data.yaml. When using routed ctlplane networks, the
parameters ``ControlPlaneSubnetCidr`` and ``ControlPlaneDefaultRoute``
will be different. So we need to use static per-role
Net::SoftwareConfig templates, and add parameters such as
``ControlPlaneDefaultRouteLeafX``.

The values the use need to pass in for these are already available in
the neutron ctlplane network configuration on the undercloud. So
ideally we should not need to ask the user to provide them in
parameter_defaults, we should resolve the correct values automatically.


: We can get the port ID using get_attr:

 {get_attr: [<server>, addresses, <network name_or_id>, 0, port]}

: From there outside of heat we can get the subnet_id:

 openstack port show 2fb4baf9-45b0-48cb-8249-c09a535b9eda \
     -f yaml -c fixed_ips

 fixed_ips: ip_address='172.20.0.10', subnet_id='2b06ae2e-423f-4a73-
97ad-4e9822d201e5'

: And finally we can get the gateway_ip and cidr of the subnet:

  openstack subnet show 2b06ae2e-423f-4a73-97ad-4e9822d201e5 \
      -f yaml -c gateway_ip -c cidr

 cidr: 172.20.0.0/26
 gateway_ip: 172.20.0.62


The problem is getting there using heat ...
a couple of ideas:

a) Use heat's ``external_resource`` to create a port resource,
   and then  a external subnet resource. Then get the data
   from the external resources. We probably would have to make
   it possible for a ``external_resource`` depend on the server
   resource, and verify that these resource have the required
   attributes.

b) Extend attributes of OS::Nova::Server (OS::Neutron::Port as
   well probably) to include the data.

   If we do this we should probably aim to be in parity with
   what is made available to clients getting the configuration
   from dhcp. (mtu, dns_domain, dns_servers, prefixlen,
   gateway_ip, host_routes, ipv6_address_mode, ipv6_ra_mode
   etc.)

c) Create a new heat function to read properties of any
   openstack resource, without having to make use of the
   external_resource in heat.




[1] https://github.com/openstack/tripleo-heat-templates/blob/9727a0d813
f5078d19b605e445d1c0603c9e777c/puppet/role.role.j2.yaml#L383-L389
[2] https://github.com/openstack/tripleo-heat-templates/blob/9727a0d813
f5078d19b605e445d1c0603c9e777c/network/config/single-nic-
vlans/role.role.j2.yaml#L21-L27