[openstack-dev] [all] devstack changing to neutron by default RSN

Sean Dague sean at dague.net
Fri Aug 5 17:21:55 UTC 2016


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.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list