Enhance DHCP agent and IP library for networking-calico interface driver
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
High
|
Nell Jerram |
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.
Changed in neutron: | |
assignee: | nobody → Neil Jerram (neil-jerram) |
Changed in neutron: | |
status: | New → In Progress |
Changed in neutron: | |
importance: | Undecided → Medium |
milestone: | none → liberty-3 |
Changed in neutron: | |
importance: | Medium → High |
Changed in neutron: | |
status: | In Progress → Fix Committed |
Changed in neutron: | |
status: | Fix Committed → Fix Released |
Changed in neutron: | |
milestone: | liberty-3 → 7.0.0 |
I'm fine with these changes, and here's a link to the reviews it indirectly references:
https:/ /review. openstack. org/#/c/ 205181/ /review. openstack. org/#/c/ 206078/ /review. openstack. org/#/c/ 206077/ /review. openstack. org/#/c/ 206079/
https:/
https:/
https:/