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

Armando M. armamig at gmail.com
Fri Aug 5 15:36:41 UTC 2016


On 5 August 2016 at 07:39, Brian Haley <brian.haley at hpe.com> wrote:

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


Test *test_connectivity_between_vms_on_different_networks*  failed on
single node twice in a row. I think that VM placement may have nothing to
do with it.


>
>
> -Brian
>
>
> __________________________________________________________________________
> 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/629ef631/attachment.html>


More information about the OpenStack-dev mailing list