yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: neutron
       Status: Fix Committed => Fix Released

-- 
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:
  Fix Released

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