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