Fixed setting the custom MTU at TF clouds by updating the ports
The MOS 22.5 cloud does not have TF version which can set the
custom MTU during the network creation. This is available only
since TF R21.4. Till that time, we can use the old way of
updating the VM ports, see [1].
Also, added the workaround for mtu field at MOS TF clouds
At the MOS TF clouds, the network payload from the API does not
containt 'mtu' attribute. Thus, we need to do the workaround. Here,
the workaround is done similarly to the CLI: it sets None for the mtu.
Also, made some PEP8 and codestile fixes.
[1] https://supportportal.juniper.net/s/article/Contrail-How-to-update-the-interface-MTU-of-an-exsiting-VMI-with-DHCP-option?language=en_US
Related-PROD: PROD-36943
Change-Id: Ieeb0dc50a29b3145b9ffaae2b7673543983fd915
diff --git a/fixtures/base.py b/fixtures/base.py
index 50e9cc7..721d772 100644
--- a/fixtures/base.py
+++ b/fixtures/base.py
@@ -81,7 +81,7 @@
os_resource['subnet1'] = subnet['id']
openstack_clients.network.add_interface_router(
- os_resource['router']['id'],{'subnet_id': os_resource['subnet1']})
+ os_resource['router']['id'], {'subnet_id': os_resource['subnet1']})
openstack_clients.network.add_interface_router(
os_resource['router']['id'],
{'subnet_id': os_resource['subnet2']['id']})
@@ -98,7 +98,7 @@
os_resource['router']['id'])
time.sleep(5)
openstack_clients.network.delete_router(os_resource['router']['id'])
- time.sleep(5)
+ time.sleep(10) # extended to 10 since fails at TF sometimes
openstack_clients.network.delete_network(os_resource['net1']['id'])
openstack_clients.network.delete_network(os_resource['net2']['id'])