Open Stack

On 10/19/2016 10:33 AM, Dan Sneddon wrote:
> I am doing research to support the spec for TripleO deployment on
> routed networks [1]. I would like some input on how to represent
> multiple subnet ranges for the provisioning network in undercloud.conf.
> 
> The Ironic Inspector dnsmasq service is currently configured using the
> puppet-ironic module, and the range of IP addresses is taken directly
> from undercloud.conf. For example, here is the .erb which configures
> /etc/ironic-inspector/dnsmasq.conf if using TFTP [2]:
> 
> ###### inspector_dnsmasq_tftp.erb ######
> port=0
> interface=<%= @dnsmasq_interface %>
> bind-interfaces
> dhcp-range=<%= @dnsmasq_ip_range %>,29
> dhcp-boot=pxelinux.0,localhost.localdomain,<%= @dnsmasq_local_ip %>
> dhcp-sequential-ip
> ############
> 
> Since there is only one dnsmasq_ip_range, only a single subnet is
> served via DHCP. What I would like to do is extend the undercloud.conf
> to support multiple IP ranges, and I'm looking for input on the best
> way to represent the data.
> 
> I am not sure if we can be fully backwards-compatible here. My gut
> feeling is no, unless we leave the existing parameters as-is and add
> something like an "additional_inspection_ipranges" parameter. The data
> that will need to be represented for each subnet is:
> 
> * Network subnet
> * Start and end of inspection IP range
> * Subnet mask (could be determined by parsing cidr, like 172.20.1.0/24)
> * Gateway router for the subnet
> 
> We could potentially represent this data as a JSON, or as a list of
> strings. Here are some potential examples:
> 
> JSON:
> additional_inspection_ipranges = [
>   {
>     "subnet": "172.20.1.0/24",
>     "start": "172.20.1.100",
>     "end": "172.20.1.120",
>     "gateway": "172.20.1.254"
>   },
>   {
>     "subnet": "172.20.2.0/24",
>     "start": "172.20.2.100",
>     "end": "172.20.2.120",
>     "gateway": "172.20.2.254"
>   }
> ]
> 
> String:
> additional_inspection_ipranges =
> "172.20.1.0,172.20.1.100,172.20.1.120,255.255.255.0,172.20.1.254;172.20.2.0,172.20.2.100,172.20.2.120,255.255.255.0,172.20.2.254"
> 
> Either of these might get unwieldy depending on the number of networks.
> Perhaps we could have a repeating parameter? Something like this:
> 
> additional_inspection_iprange =
> "172.20.1.0,172.20.1.100,172.20.1.120,255.255.255.0,172.20.1.254"
> additional_inspection_iprange =
> "172.20.2.0,172.20.2.100,172.20.2.120,255.255.255.0,172.20.2.254"
> 
> I would like some feedback about how to represent this data in a way
> that it can be easily parsed by Puppet, while remaining readable. Any
> suggestions would be very much appreciated.
> 
> [1] - https://review.openstack.org/#/c/377088
> [2] -
> https://github.com/openstack/puppet-ironic/blob/master/templates/inspector_dnsmasq_tftp.erb
> 

After writing this, I realized that I neglected to present another data
point. The Neutron DHCP agent handles this situation very well. If
there are multiple subnets that belong to a network, the ranges are all
included, and each range has a tag that matches a default-gateway that
is taken from the subnet object.

Would it be feasible to modify ironic-inspector and
ironic-inspector-dnsmasq to instead get it's configuration from a given
network. So if the provisioning network is "ctlplane", then the values
would be taken from the "ctlplane" network. This would allow us to
manipulate the values for the ironic-inspector-dnsmasq via Heat
templates or even the Neutron command-line/python client.

The advantage of this approach is that it may have side benefits for
tenant bare metal use cases.

-- 
Dan Sneddon         |  Senior Principal OpenStack Engineer
dsneddon at redhat.com |  redhat.com/openstack
dsneddon:irc        |  @dxs:twitter