On 11 October 2016 at 17:05, Clark Boylan <[email protected]> wrote:
> On Tue, Oct 11, 2016, at 05:01 PM, Armando M. wrote: > > On 11 October 2016 at 16:54, Clark Boylan <[email protected]> wrote: > > > > > On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote: > > > > On 11 October 2016 at 16:43, Clark Boylan <[email protected]> > wrote: > > > > > > > > > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote: > > > > > > On 11 October 2016 at 14:09, Clark Boylan <[email protected]> > > > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
