yahoo-eng-team team mailing list archive

[Neil Jerram <Neil.Jerram@xxxxxxxxxxxxxx>]

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