To verify vic-machine-server can create a VCH with a specified configuration
This test requires a vSphere system where VCHs can be deployed
Note: Multiple versions of tests must be implemented:
- With and without datacenter-scoped URLs.
- Using both username/password- and session-based authentication.
It should not be necessary to implement all four combinations for every test case, but full coverage should be provided for at least one of the basic test cases.
These tests are intended to verify the feature at a basic level.
These tests are intended to verify the behavior in various failure cases. We must gracefully handle invalid input and unexpected user behavior.
4. Attempt to create various VCHs with invalid networking settings (on bridge, public, management, and container networks)
(Not implemented.)
These tests are intended to verify that the API and CLI can coexist without issue.
These tests are intended to verify that the API behaves as expected when performing concurrent operations.
(Not implemented.)
(Not implemented.)
These tests are designed to mimic realistic customer scenarios. These tests will usually duplicate coverage provided by a test above, but provide additional validation around specific important workflows.
1. Create a VCH with an interesting network topology and verify that the isolation properties of the networks are as expected (using a static IP on at least one network)
(Not implemented.)
2. Create a VCH with a variety of volume stores and verify that they work as intended, including sharing of volumes
(Not implemented.)
3. Create a complex VCH using a new operations user account and the "grant permissions" feature and verify that those permissions are sufficient by exercising a variety of VCH functionality
(Not implemented.)
4. Create a VCH with interesting registry settings and a proxy and verify that those are used as expected
(Not implemented.)
(Not implemented.)