Open Stack

This brings up something I'd like to discuss.  We have a config option
called "allow_overlapping_ips" which actually defaults to False.  It
has been suggested [1] that this should be removed from Neutron and
I've just started playing around with ripping it out [2] to see what
the consequences are.

A purely L3 routed network, like Calico, is a case where it is more
complex to implement allowing overlapping ip addresses.

If we deprecate and eventually remove allow_overlapping_ips, will this
be a problem for Calico?  Is the shared address space in Calico
confined to a single flat network or do you already support tenant
private networks with this technology?  If I recall from previous
discussions, I think that it only supports Neutron's flat network
model in the current form, so I don't think it should be a problem.
Am I correct?  Please confirm.

Carl

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/036336.html
[2] https://review.openstack.org/#/c/179953/

On Fri, May 1, 2015 at 8:22 AM, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:
> 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
>>
>
> __________________________________________________________________________
> 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