Open Stack

This is a nice option for smaller deployments that didn't need the
complexity of NAT. From a custom L3 plugin perspective, it also eliminated
any single points of failure pretty easily since no NAT state had to be
distributed.

However, it was difficult to use with tenant self-service since one tenant
could create a subnet that ate up the whole routing space. It basically
required that the networking was done by an admin or that the entire
deployment was shared by a group of users trusted to do the right thing.

My main interest in the IPAM work was to support fully routable deployments
like this. Once IPAM has a workflow that covers tenant subnet allocation
from a subnet pool shared by the whole deployment, I think deprecation of
the "allow_overlapping_ips" option makes perfect sense since the operator
can just create a single global subnet pool to simulate it.

On Wed, Mar 25, 2015 at 8:29 AM, Carl Baldwin <carl at ecbaldwin.net> wrote:

> Yesterday, I got looking at another option that I had completely
> forgotten about.  It is "allow_overlapping_ips", set in neutron.conf
> and defaults to False.  It appears that when it is False, Neutron
> doesn't allow any overlapping IPs throughout the deployment, across
> all networks.  My guess is that the vast majority of deployments will
> set this to True as a matter of course.
>
> My suspicion is that this option is related to the use_namespaces
> option because if namespaces are not used, then isolating routing
> domains would not be possible on the network node.  However, there may
> be other reasons for needing this option.
>
> I'm not yet proposing this option be deprecated.  I'm asking for
> feedback from operators and others who might be using the default
> value of False.
>
> Carl
>
> On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller <amuller at redhat.com> wrote:
> > Note that https://review.openstack.org/#/c/166888/ has been merged.
> > This means that the option has been deprecated for K and will be
> > removed in L. Anyone using the non-default value of False will be looking
> > at errors in his logs.
> >
> > ----- Original Message -----
> >>
> >>
> >> On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
> >> > I see you point Van,
> >> >
> >> > In the other hand, removing it, cleans up lot of conditional code
> parts
> >> > (moving parts at the other side),
> >> > and also the non-netns case is not tested by upstream CI, AFAIK, so it
> >> > could be broken anytime
> >> > and we would not notice it.
> >> >
> >> >
> >> >
> >> > Miguel Ángel Ajo
> >> >
> >> > On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:
> >> >
> >> >>> I think there are valid reasons to not use namespaces:
> >> >>>
> >> >>>   * Fewer moving parts == less can potentialy fail
> >> >>>   * Troubleshooting is easier due to less places to look / need no
> >> >>>     familiarity with namespaces & tools
> >> >>>   * If I remember correctly setting up a namespace can get really
> >> >>>     slow when you have a lot of them on a single machine
> >> >>>
> >> >>
> >> >> > IMHO, those shouldn’t be valid reasons anymore, since they were due
> >> >> > iproute, or sudo issues
> >> >> > that have been corrected long ago, and all distros installing
> neutron
> >> >> > are supporting netns at this
> >> >>
> >> >> Well, you exactly made my point:
> >> >> There is lots that can and will go wrong with more moving parts.
> >> >> That they are fixed at the moment does not mean that there will not
> be
> >> >> a new bug in the future…
> >> >>
> >> >> Cheers,
> >> >> Robert van Leeuwen
> >> >> _______________________________________________
> >> >> OpenStack-operators mailing list
> >> >> OpenStack-operators at lists.openstack.org
> >> >> <mailto:OpenStack-operators at lists.openstack.org>
> >> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >> >
> >> >
> >> >
> >> >
> __________________________________________________________________________
> >> > 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
> >> >
> >>
> >> FWIW we were doing CI without namespaces before Kilo simply due to RHEL
> >> 6.5 not having the support w/o a kernel patch.
> >>
> >> Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that
> >> has namespace support so it's no longer an issue for us.
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt Riedemann
> >>
> >>
> >>
> __________________________________________________________________________
> >> 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
>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150325/472d012a/attachment.html>