Open Stack

On 5 August 2016 at 10:21, Sean Dague <sean at dague.net> wrote:

> On 08/05/2016 11:34 AM, Armando M. wrote:
> >
> >
> > On 5 August 2016 at 05:59, Sean Dague <sean at dague.net
> > <mailto:sean at dague.net>> wrote:
> >
> >     On 08/04/2016 09:15 PM, Armando M. wrote:
> >     > So glad we are finally within the grasp of this!
> >     >
> >     > I posted [1], just to err on the side of caution and get the
> opportunity
> >     > to see how other gate jobs for Neutron might be affected by this
> change.
> >     >
> >     > Are there any devstack-gate changes lined up too that we should be
> aware of?
> >     >
> >     > Cheers,
> >     > Armando
> >     >
> >     > [1] https://review.openstack.org/#/c/351450/
> >     <https://review.openstack.org/#/c/351450/>
> >
> >     Nothing at this point. devstack-gate bypasses the service defaults in
> >     devstack, so it doesn't impact that at all. Over time we'll want to
> make
> >     neutron the default choice for all devstack-gate setups, and
> nova-net to
> >     be the exception. But that actually can all be fully orthoginal to
> this
> >     change.
> >
> >
> > Ack
> >
> >
> >     The experimental results don't quite look in yet, it looks like one
> test
> >     is failing on dvr (which is the one that tests for cross tenant
> >     connectivity) -
> >     http://logs.openstack.org/50/350750/5/experimental/gate-
> tempest-dsvm-neutron-dvr/4958140/
> >     <http://logs.openstack.org/50/350750/5/experimental/gate-
> tempest-dsvm-neutron-dvr/4958140/>
> >
> >     That test has been pretty twitchy during this patch series, and it's
> >     quite complex, so figuring out exactly why it's impacted here is a
> bit
> >     beyond me atm. I think we need to decide if that is going to get
> deeper
> >     inspection, we live with the fails, or we disable the test for now
> so we
> >     can move forward and get this out to everyone.
> >
> >
> > Looking at the health trend for DVR [1], the test hasn't failed in a
> > while, so I wonder if this is induced by the proposed switch, even
> > though I can't correlate it just yet (still waiting for caffeine to kick
> > in). Perhaps we can give ourselves today to look into it and pull the
> > trigger for 351450 <https://review.openstack.org/#/c/351450/> on Monday?
> >
> > [1] http://status.openstack.org/openstack-health/#/job/gate-
> tempest-dsvm-neutron-dvr
>
> The only functional difference in the new code that happens in the gate
> is the iptables rule:
>
>         local default_dev=""
>         default_dev=$(ip route | grep ^default | awk '{print $5}')
>         sudo iptables -t nat -A POSTROUTING -o $default_dev -s
> $FLOATING_RANGE -j MASQUERADE
>
> That's the thing to consider. It is the bit that's a little janky, but
> it was the best idea we had for making things act like we expect
> otherwise on the single node environment (especially guests being able
> to egress). It's worth noting, we never seem to test guest egress in the
> gate (at least not that I could find), so this is something that might
> just never have been working the way we expected.
>

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...

[1]
http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr/85f8633/logs/testr_results.html.gz
[2] https://launchpad.net/bugs/1609693
[3] https://review.openstack.org/#/c/340659/
[4]
http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr-multinode-full/8d9ac8f/logs/testr_results.html.gz


>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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/20160805/63039d43/attachment.html>