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

Brian Haley brian.haley at hpe.com
Fri Aug 5 14:39:43 UTC 2016


On 08/05/2016 08:59 AM, Sean Dague 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/
>
> 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.
>
> 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/
>
> 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.

I took a quick look at this and can't reproduce it yet, here's what the test 
seems to do:

1a. Create a network/subnet (10.100.0.0/28)
  b. attach a router interface to the subnet
  c. boot VM1 on the network

2a. Create a network/subnet (10.100.0.16/28)
  b. do NOT attach a router interface to the subnet
  c. boot VM2 on the network

3. Ssh to VM1 and ping VM2 - it should fail since there's no route to the 
network, but it succeeds

The only place you should be able to ping that VM2 IP from is the dhcp 
namespace, which does work for me.

So if you are seeing it be flaky it could the VM placement (same host vs 
different host) is impacting it?  In the logs it showed the same hostId, but so 
did my test, so I don't have a good answer.

-Brian



More information about the OpenStack-dev mailing list