Open Stack

On 11 October 2016 at 17:05, Clark Boylan <cboylan at sapwetik.org> wrote:

> On Tue, Oct 11, 2016, at 05:01 PM, Armando M. wrote:
> > On 11 October 2016 at 16:54, Clark Boylan <cboylan at sapwetik.org> wrote:
> >
> > > On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote:
> > > > On 11 October 2016 at 16:43, Clark Boylan <cboylan at sapwetik.org>
> wrote:
> > > >
> > > > > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > > > > > On 11 October 2016 at 14:09, Clark Boylan <cboylan at sapwetik.org>
> > > wrote:
> > > > > >
> > > > > > > Hello everyone,
> > > > > > >
> > > > > > > Currently multinode testing + neutron is broken in clouds that
> use
> > > > > > > portions of 10.0.0.0/8 for their networking due to route
> conflicts
> > > > > with
> > > > > > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> > > > > s/1629133
> > > > > > > is tracking the issue for us. I would like to see this get
> resolved
> > > > > > > properly before we do further work on multinode testing as it
> is
> > > > > > > difficult to review and determine what failures are legit vs
> which
> > > > > > > failures are related to this bug and whether or not a specific
> > > > > multinode
> > > > > > > test has decided to workaround the issue.
> > > > > > >
> > > > > > > The change to use subnet pools in devstack is a non backward
> > > compatible
> > > > > > > change for devstack currently and it doesn't appear to have
> been
> > > > > > > documented in devstack at all. Would be great if we can
> finally fix
> > > > > this
> > > > > > > and get testing back to working and however we fix it ensure
> that
> > > > > > > devstack has the appropriate documentation.
> > > > > > >
> > > > > >
> > > > > > What is holding [1] back? Merging that would resolve the issue,
> then
> > > we
> > > > > > can
> > > > > > drill down into why subnetpools interfere with the underlying
> > > networking
> > > > > > setup. I have asked Carl to look into broken build [2]
> > > > > >
> > > > > > [1] https://review.openstack.org/#/c/379543/
> > > > > > [2]
> > > > > > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> > > > > m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
> > > > >
> > > > > Yours is one of the two -1's on the change :) I think that devstack
> > > core
> > > > > is probably holding back due to the two -1s there. If we are ok
> with
> > > > > iterating on making it better rather than all in one shot maybe
> that
> > > > > change is good for now and we can update the reviews?
> > > > >
> > > >
> > > > Well, that means the ball is in the contributor's court, who is
> supposed
> > > > to
> > > > address reviewers' concerns :)
> > > >
> > > The comments on the change with -1's are opposed to doing what the
> > > change does. I don't know how I can possibly address them.
> > >
> >
> > Then say so on the review and I am happy to rephrase to make sure I get
> > my
> > message across correctly. If you let the review rot how can you expect it
> > to make progress? That's like Openstack 101
>
> It does say so clearly in the commit itself:
>
> "It turns out that many people have already chosen fixed ranges that
> work for their environments. They have done so to avoid conflicts with
> existing networking ranges and routing. The change to use 10.0.0.0/8 and
> apply routes for this network to neutron interfaces prevents anyone from
> using networks within that range for anything else.
>
> For example imagine you have a cloud provider that provides private IPv4
> addresses allocated out of ranges in 10.0.0.0/8 and they do all public
> networking over ipv6. This change to devstack prevents you from using
> those private networks properly after starting neutron with devstack.
> However, in situations like this FIXED_RANGE should already represent a
> safe range to use so just use it."
>
> The comments both refuse to allow FIXED_RANGE as the default and its the
> only reason I pushed that patch. I personally believe this is the right
> fix, if neutron/devstack disagree they should feel welcome to propose
> alterantives, but I am not going to not use FIXED_RANGE when it was the
> whole point of the change in the first place.
>
>
Okay at least I am glad we got this clarified :)

This discussion gave me the opportunity to drill down further,  and looking
at this more closely, the issue seems to stem from [1], which fiddles with
the routing table and it caused other troubles [2]. The original use of
subnetpools as introduced by [3] should not have side effects whatsoever.
At this point I feel that changing the pool range is even less justified.
If I had seen bug [4], I would have been against its fix, because you're
absolutely right as the change being not backward compatible.

[1] https://review.openstack.org/#/c/356026
[2] https://bugs.launchpad.net/devstack/+bug/1628267
[3] https://review.openstack.org/#/c/282559/
[4] https://bugs.launchpad.net/devstack/+bug/1613717


> Clark
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161011/59c61713/attachment.html>