On 5 August 2016 at 11:25, Armando M. <arma...@gmail.com> wrote: > > > On 5 August 2016 at 10:21, Sean Dague <s...@dague.net> wrote: > >> On 08/05/2016 11:34 AM, Armando M. wrote: >> > >> > >> > On 5 August 2016 at 05:59, Sean Dague <s...@dague.net >> > <mailto:s...@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-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
