On Mon, Apr 23, 2018 at 10:16 AM, Harald Jensås <[email protected]> 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 <[email protected]> > > 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 [email protected] | redhat.com/openstack dsneddon:irc | @dxs:twitter
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
