nagaboinaramgopal opened a new pull request, #14176:
URL: https://github.com/apache/cloudstack/pull/14176
### 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
- [x] test (unit or integration test code)
### Feature/Enhancement Scale or Bug Severity
#### Feature/Enhancement Scale
- [ ] Major
- [ ] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [ ] Major
- [x] 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
