test: run the deployment planner and metrics smoke tests in their own network instead of the shared admin network

[nagaboinaramgopal]

Description

test_vm_deployment_planner.py and the VM tests in test_metrics_api.py deploy their VMs without an account or a network, so the VMs land in the calling account's default network. On Trillian that is the admin's shared network, and when its router is stuck or an earlier test has left the network in Shutdown, all five planner tests fail with "Unable to orchestrate the start of VM instance" (for example tid-16935 on #13753 and tid-16908 on #13884), and the VM metrics tests fail the same way (tid-16968 on #11968). Both files already create an account, but the deploys never use it.

This creates an L2 network owned by the test account and deploys into it (for the metrics test only in advanced zones, since it also runs in basic zones), and in the vms and volumes usage history tests it waits until the history has stats instead of sleeping a fixed two minutes.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

N/A

How Has This Been Tested?

Ran both files with Marvin against a KVM advanced zone. The calls ran as an account that owns more than one isolated network in that zone, which breaks the same dependency on the caller's default network in another way.

test_vm_deployment_planner.py before the change, all five tests error in 0.1 seconds:

deployvirtualmachine failed, due to: errorCode: 431, errorText:More than 1 default Isolated networks are found for Account ...; please specify networkIds

After the change, all five pass (about 134 seconds each) and the VMs are deployed in the test account's L2 network.

test_metrics_api.py passes on this zone both before and after (14 tests), but before the change the admin VMs were deployed in the admin account's isolated admin-network and the user VM in an isolated network created for the test account on the fly, both behind a virtual router, which is the dependency that fails on Trillian. After the change all four VMs are in the test account's L2 network. Waiting for stats instead of sleeping also shortens the history tests:

test                                 before    after
test_list_vms_metrics_admin          183 s     134 s
test_list_vms_metrics_user           184 s     134 s
test_list_vms_metrics_history        140 s      46 s
test_list_volumes_metrics_history    139 s      30 s

How did you try to break it?

Checked that the L2 network and its offering are removed when the class is torn down (the class cleanup runs in reverse order, so the network goes before the offering and the account). The zone used here is an advanced zone; in a basic zone the metrics test creates no L2 network and passes no network id, so its deploys are the same as before.