Open Stack

On Mon, Apr 23, 2018 at 10:16 AM, Harald Jensås <hjensas at redhat.com> wrote:

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

We could add the ControlPlaneDefaultRoute and ControlPlaneSubnetCidr to
network_data.yaml, but this would involve some duplication of configuration
data, since those are currently defined in undercloud.conf. A more robust
solution might be to generate network_data.yaml from that info in
undercloud.conf, but currently we don't modify any files in the
tripleo-heat-templates package after it gets installed.


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

Yes, the port is currently created as part of the Ironic server resource.
We would have more flexibility if this were a separate Neutron port, but we
need to be able to support upgrades. This would require the ability in Heat
to detach the implicit port from the Ironic resource, and attach a Neutron
port resource with the same IP to a node without rebuilding the entire
node. This isn't currently possible.


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

I can't speak to the roadmap of Heat/Neutron/Nova on the undercloud, for
the immediate future I don't see us moving away from Heat entirely due to
upgrade requirements.

I can see another use case for this Heat functionality, which is that I
would like to be able to generate a report using Heat that lists all the
ports in use in the entire deployment. This would be generated
post-deployment, and could be used to populate an external DNS server, or
simply to report on which IPs belong to which nodes.

-- 
Dan Sneddon         |  Senior Principal OpenStack Engineer
dsneddon at redhat.com |  redhat.com/openstack
dsneddon:irc        |  @dxs:twitter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180423/ff3beb90/attachment.html>