Open Stack

On Fri, 2018-04-20 at 14:44 +0200, Thomas Herve wrote:
> 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.
> 
No, the networks defined in network_data.yaml is fine, that is the data
used to create the neutron stuff so passing the data from there is
already in place to some extent.

But, the ctlplane network is not defined in network_data.yaml.

> 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.
> 
In tripleo, the ctlplane interface is an implicit port created by the
server resource. :( (Attempts where made to change this, but upgrades
would'nt work) So the server resource is where I would find it most
useful. (Adding attributes to the port resource, and then using
external resource for the implicit server ports may be a compromise.
Nested dependencies for external_resources might be hard?)

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

Guess what I envision is a client_config attribute, a map with data
useful to configure a network interface on the client. (I put * on the
ones I believe could be useful for TripleO)

* /v2.0/networks/{network_id}/mtu              
/v2.0/networks/{network_id}/dns_domain
* /v2.0/subnets/{subnet_id}/dns_nameservers    
* /v2.0/subnets/{subnet_id}/host_routes        
/v2.0/subnets/{subnet_id}/ip_version
* /v2.0/subnets/{subnet_id}/gateway_ip
* /v2.0/subnets/{subnet_id}/cidr
* /v2.0/subnets/{subnet_id}/ipv6_address_mode
* /v2.0/subnets/{subnet_id}/ipv6_ra_mode
/v2.0/ports/{port_id}/description             - Why not?
/v2.0/ports/{port_id}/dns_assignment
/v2.0/ports/{port_id}/dns_domain
/v2.0/ports/{port_id}/dns_name
* /v2.0/ports/{port_id}/fixed_ips             - We have this already
/v2.0/ports/{port_id}/name                    - Why not?


I've added Dan Sneddon on CC as well. Guess there is the question if
TripleO will/want to continue using heat, neutron, nova etc.



//
Harald