Hello,

NetApp CI has been facing the same problem.

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@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