Public bug reported:
networking-calico will very shortly provide an ML2 mechanism driver,
DHCP agent interface driver and Devstack plugin to demonstrate the
Calico project's idea of using routing - rather than bridging - to
provide IP-level connectivity between VMs.
The existing Neutron DHCP agent provides a great deal of value in terms
of managing Dnsmasq, and of mapping from Neutron data to Dnsmasq config,
and networking-calico would very much like to reuse that value, rather
than say implementing its own DHCP agent. But, the DHCP agent needs two
changes to allow it to provide DHCP service correctly and efficiently in
the compute host environment that networking-calico sets up.
1. It needs to invoke Dnsmasq with some different options, because of
TAP interfaces in the networking-calico setup not being bridged.
2. It does not need to allocate a unique IP address, from each DHCP-
enabled subnet, in each place that it runs. Instead it can use each
subnet's gateway IP address.
Also in core Neutron there is an IP library module that provides methods
for creating certain types of Linux network interfaces. networking-
calico's interface driver uses a 'dummy' interface as the placeholder
for Dnsmasq's DHCP context information and for the subnet prefix, but
the IP library does not yet support the creation of such dummy
interfaces. For consistency, therefore, it also makes sense to enhance
the IP library so that it supports creation of dummy interfaces.
Please note that, although much work remains to define how routed
networking is represented in the Neutron API and data model, there are
two reasons why it makes sense to proceed with these DHCP agent and IP
library changes now.
The Neutron-technical reasons is this: whatever API we end up with for
routed networking, the DHCP agent code will need to be able to provide
DHCP service to unbridged TAP interfaces, just as this bug describes;
and the behaviour of the DHCP agent code is not actually driven by API
properties, but by a config-defined interface driver. Therefore, when
the API for routed networking is decided, the changes covered by this
bug will still be correct.
The pragmatic / OpenStack community reason is that we (meaning the
Calico project) already have several operators interested in and
trialling this form of connectivity (even if it means accepting some
semantic departures from the current Neutron API), and it will be a
major help to both them and us if it is possible, as of the Liberty
release, to do this with a vanilla Neutron release.
** Affects: neutron
Importance: Undecided
Assignee: Neil Jerram (neil-jerram)
Status: New
** Tags: rfe
** Changed in: neutron
Assignee: (unassigned) => Neil Jerram (neil-jerram)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1486649
Title:
Enhance DHCP agent and IP library for networking-calico interface
driver
Status in neutron:
New
Bug description:
networking-calico will very shortly provide an ML2 mechanism driver,
DHCP agent interface driver and Devstack plugin to demonstrate the
Calico project's idea of using routing - rather than bridging - to
provide IP-level connectivity between VMs.
The existing Neutron DHCP agent provides a great deal of value in
terms of managing Dnsmasq, and of mapping from Neutron data to Dnsmasq
config, and networking-calico would very much like to reuse that
value, rather than say implementing its own DHCP agent. But, the DHCP
agent needs two changes to allow it to provide DHCP service correctly
and efficiently in the compute host environment that networking-calico
sets up.
1. It needs to invoke Dnsmasq with some different options, because of
TAP interfaces in the networking-calico setup not being bridged.
2. It does not need to allocate a unique IP address, from each DHCP-
enabled subnet, in each place that it runs. Instead it can use each
subnet's gateway IP address.
Also in core Neutron there is an IP library module that provides
methods for creating certain types of Linux network interfaces.
networking-calico's interface driver uses a 'dummy' interface as the
placeholder for Dnsmasq's DHCP context information and for the subnet
prefix, but the IP library does not yet support the creation of such
dummy interfaces. For consistency, therefore, it also makes sense to
enhance the IP library so that it supports creation of dummy
interfaces.
Please note that, although much work remains to define how routed
networking is represented in the Neutron API and data model, there are
two reasons why it makes sense to proceed with these DHCP agent and IP
library changes now.
The Neutron-technical reasons is this: whatever API we end up with
for routed networking, the DHCP agent code will need to be able to
provide DHCP service to unbridged TAP interfaces, just as this bug
describes; and the behaviour of the DHCP agent code is not actually
driven by API properties, but by a config-defined interface driver.
Therefore, when the API for routed networking is decided, the changes
covered by this bug will still be correct.
The pragmatic / OpenStack community reason is that we (meaning the
Calico project) already have several operators interested in and
trialling this form of connectivity (even if it means accepting some
semantic departures from the current Neutron API), and it will be a
major help to both them and us if it is possible, as of the Liberty
release, to do this with a vanilla Neutron release.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1486649/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
