Open Stack

Thanks for your reply, Kevin, and sorry for the delay in following up.

On 21/04/15 09:40, Kevin Benton wrote:
> Is it compatible with overlapping IPs? i.e. Will it give two different
> VMs the same IP address if the reservations are setup that way?

No, not as I've described it below, and as we've implemented Calico so 
far.  Calico's first target is a shared address space without 
overlapping IPs, so that we can handle everything within the default 
namespace.

But we do also anticipate a future Calico release to support private 
address spaces with overlapping IPs, while still routing all VM data 
rather than bridging.  That will need the private address TAP interfaces 
to go into a separate namespace (per address space), and have their data 
routed there; and we'd run a Dnsmasq in that namespace to provide that 
space's IP addresses.

Within each namespace - whether the default one or private ones - we'd 
still use the other changes I've described below for how the DHCP agent 
creates the ns-XXX interface and launches Dnsmasq.

Does that make sense?  Do you think that this kind of approach could be 
in scope under the Neutron umbrella, as an alternative to bridging the 
TAP interfaces?

Thanks,
	Neil


> On 16/04/15 15:12, Neil Jerram wrote:
>
>     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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>