[devstack][neutron][manila] Instances having trouble getting to external network with OVN

Goutham Pacha Ravi gouthampravi at gmail.com
Tue Aug 24 18:21:30 UTC 2021


Hi,

Bubbling up this issue - I reported a launchpad bug with some more debug
information:
https://bugs.launchpad.net/bugs/1939627

I’m confused how/why only the Manila gates are hitting this issue. If
you’re reading - do you have any tests elsewhere that setup a nova instance
on a devstack and ping/communicate with the internet/outside world? If yes,
I’d love to compare configuration with your setup.

Thank you so much for your help,

Goutham

On Wed, Jul 21, 2021 at 12:07 PM Goutham Pacha Ravi <gouthampravi at gmail.com>
wrote:

> On Wed, Jul 14, 2021 at 2:21 PM Carlos Silva <ces.eduardo98 at gmail.com>
> wrote:
>
>> Hello,
>>
>> NetApp CI has been facing the same problem.
>>
>
> Thank you Carlos!
>
>
>>
>> Here is a local.conf we have been using in our CI:
>> https://paste.openstack.org/show/807484/
>> The tests had basically same output described by Goutham:
>> https://paste.openstack.org/show/807486/
>>
>> I have also tried this in a development environment in our lab but the
>> same issue is occurring.
>>
>>
>> Em ter., 13 de jul. de 2021 às 18:20, Goutham Pacha Ravi <
>> gouthampravi at gmail.com> escreveu:
>>
>>> Hi,
>>>
>>> Some third party storage CI running against manila repos has had issues
>>> setting up VMs and providing access to external resources in devstack;
>>> these issues started around the time that the default ml2 plugin was
>>> switched to OVN. Folks in the manila team aren't familiar with devstack/CI
>>> networking to determine how to resolve these; and we'd totally appreciate
>>> help from networking experts in this regard.
>>>
>>> A sample local.conf file used by the CI is here:
>>> http://paste.openstack.org/show/807449/
>>>
>>> Manila's tests:
>>>     - create a private tenant network
>>>     - setup a router that connects the private network to the public
>>> network
>>>     - create a nova VM on the private tenant network
>>>     - attempt to mount a share via NFS from within this VM
>>>
>>> The final step fails because the NFS mount command times out within the
>>> test VM:
>>>
>>> tempest.lib.exceptions.SSHExecCommandFailed: Command 'sudo mount -vt nfs
>>> "10.16.xx.xx:/share-96ae8d0c-8bab-4fcd-b278-51a6f473e03c-manila" /mnt',
>>> exit status: 32, stderr:
>>> mount.nfs: mount(2): Connection timed out
>>> mount.nfs: Connection timed out
>>>
>>>
>>> stdout:
>>> mount.nfs: timeout set for Mon Jun 28 14:47:19 2021
>>> mount.nfs: trying text-based options
>>> 'vers=4.2,addr=10.16.xx.xx,clientaddr=10.1.0.26'
>>>
>>>
>>>
>>> The timeout seems to be because the VM is unable to reach the NFS server
>>> that's external to the devstack host. The NFS server is reachable from the
>>> devstack host.
>>>
>>> Have there been any changes to devstack configuration that we need to be
>>> aware of, wrt VMs having access to the external network?
>>>
>>> Thanks,
>>> Goutham
>>>
>>
> Ping Neutron developers,
>
> Can you help vet this devstack issue; folks in the manila third party CI
> community will be happy to share further logs or details.
> As an example, failure logs on a third party CI job are here:
> http://openstack-logs.purestorage.com/84/789384/25/thirdparty-check/pure-devstack-manila-tempest-aio/6965033/
> <http://openstack-logs.purestorage.com/84/789384/25/thirdparty-check/pure-devstack-manila-tempest-aio/6965033/>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210824/98219272/attachment.html>


More information about the openstack-discuss mailing list