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