[openstack-dev] [all] devstack changing to neutron by default RSN
Armando M.
armamig at gmail.com
Fri Aug 5 18:32:27 UTC 2016
On 5 August 2016 at 11:25, Armando M. <armamig at gmail.com> wrote:
>
>
> 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-tem
>> pest-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-temp
>> est-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
>>
>
I skipped this in [0], to give us further data points....clasping at straws
still.
[0] https://review.openstack.org/#/c/351876/
>
>> 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:unsubscrib
>> e
>> 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/160c27ae/attachment.html>
More information about the OpenStack-dev
mailing list