settingsLogin | Registersettings

Re: [openstack-dev] [tripleo][ironic][puppet] Spine/Leaf: Adding Multiple Subnets to ironic-inspector-dnsmasq

0 votes

On Wed, Oct 19, 2016 at 11:33 AM, Dan Sneddon dsneddon@redhat.com 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]:

# inspectordnsmasqtftp.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 dnsmasqiprange, 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.

So I think this is just an issue with the current implementation. I
think the awkwardness comes from trying to configure dnsmasq
specifically for the inspector use case and we may have tied them too
closely together in a inflexible fashion. dnsmasq supports a
configuration folder that we could use instead which would allow us to
create as many of these as we'd like. For example over in fuel[0],
the fuel master supports something similar and it uses multiple
configuration files to handle the case of additional dhcp ranges. We
could extend the puppet-ironic to support something similar if we can
configure the underlying dnsmasq to point to a configuration
directory. If we create a ironic::inspector::dhcp_range resource then
the way to configure these extra ranges, then it is just an array of
hashes in hiera and it becomes much easier to manage than the proposed
data representation. Additionally this would support the current
implementation (no change) and multiple ranges (new resource) with
little effort.

Thanks,
-Alex

[0] https://github.com/openstack/fuel-library/blob/master/deployment/puppet/fuel/manifests/dnsmasq/dhcp_range.pp

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 "additionalinspectionipranges" 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:
additionalinspectionipranges = [
{
"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:
additionalinspectionipranges =
"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:

additionalinspectioniprange =
"172.20.1.0,172.20.1.100,172.20.1.120,255.255.255.0,172.20.1.254"
additionalinspectioniprange =
"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
--
Dan Sneddon | Senior Principal OpenStack Engineer
dsneddon@redhat.com | redhat.com/openstack
dsneddon:irc | @dxs:twitter


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 19, 2016 in openstack-dev by aschultz_at_redhat.c (5,800 points)   2 2 4
retagged Jan 26, 2017

2 Responses

0 votes

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

# inspectordnsmasqtftp.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 dnsmasqiprange, 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 "additionalinspectionipranges" 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:
additionalinspectionipranges = [
{
"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:
additionalinspectionipranges =
"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:

additionalinspectioniprange =
"172.20.1.0,172.20.1.100,172.20.1.120,255.255.255.0,172.20.1.254"
additionalinspectioniprange =
"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@redhat.com | redhat.com/openstack
dsneddon:irc | @dxs:twitter


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 19, 2016 by Dan_Sneddon (2,000 points)   1 3
0 votes

On 19/10/16 18:33, 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.
[snip]

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

#

Just to note, there's no problem with this at the dnsmasq level: you can
specify as many dhcp-range options as you like, one per IP range.
There's no need to break the configuration up into multiple files to
support this.

We could potentially represent this data as a JSON, or as a list of
strings.

I vote for JSON (or maybe YAML?) over creating our own ad-hoc string format.

String:
additionalinspectionipranges =
"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"

If we're creating a string format, the obvious approach is to re-use the
one dnsmasq uses, which is

[,|][,[,]][,]

If the DHCP server is directly connected to a given network, it can
deduce the netmask by querying the interface configuration.

OTOH,

  • that doesn't specify gateway
  • I don't like the idea of directly pasting structured strings into
    configuration files without validating their structure, and the
    temptation to do that would be great.

Miles


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 21, 2016 by Miles_Gould (1,260 points)   1
...