<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 August 2016 at 11:25, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 5 August 2016 at 10:21, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On 08/05/2016 11:34 AM, Armando M. wrote:<br>
><br>
><br>
> On 5 August 2016 at 05:59, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br>
</span><div><div>> <mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>> wrote:<br>
><br>
>     On 08/04/2016 09:15 PM, Armando M. wrote:<br>
>     > So glad we are finally within the grasp of this!<br>
>     ><br>
>     > I posted [1], just to err on the side of caution and get the opportunity<br>
>     > to see how other gate jobs for Neutron might be affected by this change.<br>
>     ><br>
>     > Are there any devstack-gate changes lined up too that we should be aware of?<br>
>     ><br>
>     > Cheers,<br>
>     > Armando<br>
>     ><br>
>     > [1] <a href="https://review.openstack.org/#/c/351450/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/351450/</a><br>
>     <<a href="https://review.openstack.org/#/c/351450/" rel="noreferrer" target="_blank">https://review.openstack.<wbr>org/#/c/351450/</a>><br>
><br>
>     Nothing at this point. devstack-gate bypasses the service defaults in<br>
>     devstack, so it doesn't impact that at all. Over time we'll want to make<br>
>     neutron the default choice for all devstack-gate setups, and nova-net to<br>
>     be the exception. But that actually can all be fully orthoginal to this<br>
>     change.<br>
><br>
><br>
> Ack<br>
><br>
><br>
>     The experimental results don't quite look in yet, it looks like one test<br>
>     is failing on dvr (which is the one that tests for cross tenant<br>
>     connectivity) -<br>
>     <a href="http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr/4958140/" rel="noreferrer" target="_blank">http://logs.openstack.org/50/<wbr>350750/5/experimental/gate-tem<wbr>pest-dsvm-neutron-dvr/4958140/</a><br>
>     <<a href="http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr/4958140/" rel="noreferrer" target="_blank">http://logs.openstack.org/<wbr>50/350750/5/experimental/gate-<wbr>tempest-dsvm-neutron-dvr/49581<wbr>40/</a>><br>
><br>
>     That test has been pretty twitchy during this patch series, and it's<br>
>     quite complex, so figuring out exactly why it's impacted here is a bit<br>
>     beyond me atm. I think we need to decide if that is going to get deeper<br>
>     inspection, we live with the fails, or we disable the test for now so we<br>
>     can move forward and get this out to everyone.<br>
><br>
><br>
> Looking at the health trend for DVR [1], the test hasn't failed in a<br>
> while, so I wonder if this is induced by the proposed switch, even<br>
> though I can't correlate it just yet (still waiting for caffeine to kick<br>
> in). Perhaps we can give ourselves today to look into it and pull the<br>
</div></div>> trigger for 351450 <<a href="https://review.openstack.org/#/c/351450/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/351450/</a>> on Monday?<br>
><br>
> [1] <a href="http://status.openstack.org/openstack-health/#/job/gate-tempest-dsvm-neutron-dvr" rel="noreferrer" target="_blank">http://status.openstack.org/op<wbr>enstack-health/#/job/gate-temp<wbr>est-dsvm-neutron-dvr</a><br>
<br>
The only functional difference in the new code that happens in the gate<br>
is the iptables rule:<br>
<br>
        local default_dev=""<br>
        default_dev=$(ip route | grep ^default | awk '{print $5}')<br>
        sudo iptables -t nat -A POSTROUTING -o $default_dev -s<br>
$FLOATING_RANGE -j MASQUERADE<br></blockquote></div></div></div></div></div></blockquote><div><br></div><div>I skipped this in [0], to give us further data points....clasping at straws still.</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/351876/">https://review.openstack.org/#/c/351876/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
That's the thing to consider. It is the bit that's a little janky, but<br>
it was the best idea we had for making things act like we expect<br>
otherwise on the single node environment (especially guests being able<br>
to egress). It's worth noting, we never seem to test guest egress in the<br>
gate (at least not that I could find), so this is something that might<br>
just never have been working the way we expected.<br></blockquote><div><br></div></div></div><div>Latest run showed that the single node passed the test [1] (though it failed on bug [2] for which we have a fix in place [3]). However the multi-node failed on the same again [4]. I'll keep on digging...</div><div><br></div><div>[1] <a href="http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr/85f8633/logs/testr_results.html.gz" target="_blank">http://logs.openstack.org/<wbr>50/350750/5/experimental/gate-<wbr>tempest-dsvm-neutron-dvr/<wbr>85f8633/logs/testr_results.<wbr>html.gz</a></div><div>[2] <a href="https://launchpad.net/bugs/1609693" target="_blank">https://launchpad.net/<wbr>bugs/1609693</a></div><div>[3] <a href="https://review.openstack.org/#/c/340659/" target="_blank">https://review.openstack.<wbr>org/#/c/340659/</a></div><div>[4] <a href="http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr-multinode-full/8d9ac8f/logs/testr_results.html.gz" target="_blank">http://logs.openstack.org/<wbr>50/350750/5/experimental/gate-<wbr>tempest-dsvm-neutron-dvr-<wbr>multinode-full/8d9ac8f/logs/<wbr>testr_results.html.gz</a></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div><div><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>