Open Stack

On Thu, Apr 19, 2018 at 2:59 PM, Harald Jensås <hjensas at redhat.com> wrote:
> Hi,

Hi, thanks for sending this. Responses inline.

> 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.

To make it clear, what you want to prevent is the need to add more
keys in network_data.yaml?

As those had to be provided at some point, I wonder if tripleo can't
find a way to pass them again on the overcloud deploy.

Inspecting neutron is an elegant solution, though.

> : 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.

I believe that's a relatively easy fix. It's unclear why we didn't
allow that in the first place, probably because we were missing a use
case, but it seems valuable here.

> 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.)

I'm with you on exposing more neutron data to the Port resource. It
can be complicated because some of them are implementation specific,
but we can look into those.

I don't think adding them directly to the Server resource makes a ton
of sense though.

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

It's an interesting idea, but I think it would look a lot like what
external resources are supposed to be.

I see a few changes:
 * Allow external resource to depend on other resources
 * Expose more port attributes
 * Expose more subnet attributes

If you can list the attributes you care about that'd be great.

Thanks,

-- 
Thomas