Open Stack

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.

Clark