Open Stack

I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq 
with options such that it works (=> provides DHCP service) for TAP 
interfaces that are _not_ bridged to the DHCP interface (ns-XXX).  For 
the sake of being concrete, this involves:

- creating the ns-XXX interface as a dummy, instead of as a veth pair

- launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* 
--bridge-interface=ns-XXX,tap*

- not running in a separate namespace

- running the DHCP agent on every compute host, instead of only on the 
network node

- using the relevant subnet's gateway IP on the ns-XXX interface (on 
every host), instead of allocating a different IP for each ns-XXX interface.

I proposed a spec for this in the Kilo cycle [1], but it didn't get 
enough traction, and I'm now wondering what to do with this 
work/function.  Specifically, whether to look again at integrating it 
into Neutron during the Liberty cycle, or whether to maintain an 
independent DHCP agent for my project outside the upstream Neutron tree. 
  I would very much appreciate any comments or advice on this.

For answering that last question, I suspect the biggest factor is 
whether routed TAP interfaces - i.e. forms of networking implementation 
that rely on routing data between VMs instead of bridging it - is in 
scope for Neutron, at all.  If it is, I understand that there could be a 
lot more detail to work on, such as how it meshes with other Neutron 
features such as DVR and the IPAM work, and that it might end up being 
quite different from the blueprint linked below.  But it would be good 
to know whether this would ultimately be in scope and of interest for 
Neutron at all.

Please do let me now what you think.

Many thanks,	
	Neil

[1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs