Some refactoring to make class loading a little more logical
Removed fw global (does not persist accross modules)
Added first tests
Added command line call to set and disable redundancy
Added command line call to set master
Also found condition inw hich apache would be miscobfigured and failed to run (I love tests!!)
Fixed configure.py to cover this case
Added a test to provoke this case!
Fixed tests to use /var/cache/cloud
Added some test files but will remove them when tests are properly completed
Fixed a bug in configure that did not deal well with databags with empty dev sections
These are failing on my machine with cloud.log lines like
2014-08-07 14:34:09,509 Add dev eth2 table Table_eth2 10.0.2.0/24
2014-08-07 14:34:09,511 Address 10.0.2.106/24 on device eth2 not configured
2014-08-07 14:34:10,513 Device eth2 cannot be configured - device was not found
I think it's correct that they are failing -- this is work in progress.
This approach is instead of serverspec, but filling the same purpose. It's
main advantage is that it uses nose and python, just like the existing
marvin-based integration test suite.
Revert "Automation of CCP Objects Verification after external changes made to the original setup Purpose of this code:"
This reverts commit 7461297f3e.
Generate CCP Objects (VMs, Volumes, Snapshots, VPC, etc..) and CCP Use Cases (Networking, Data Content,etc) before an external action on the CCP Setup and verify the integrity of the CCP Objects and the Use Cases after the external action on the CCP Setup. The integrity of the CCP Objects is verified by performing operations that test the Usability of the objects. This validates the intactness of the setup after an external action. The submitted patch covers only few major use cases. It proves that similar code can be added in future to address similar goals in verifying the integrity of CCP objects belonging to different components of the product.
The code format can be followed to verify validity of real time business use cases while any code changes (CCP,hypervisor,external devices code, etc…) happen over a period of time.
The following are the scenarios that the code format can be used for:
1.Upgrade Validity Verification
a. CCP Upgrade
b. Hypervisors Upgrade
c. External Devices Upgrade
d. System VM Template Changes.
2.Patch Validity Verification
Code can be used as one of the primary Components to validity Upgrades. It will facilitate the automation of Upgrade Test Verification completely.
How to use the code:
*Kindly make the corresponding substitutions in the commands listed below.
Execute:
nosetests --with-marvin --marvin-config=$CONFIG $BASEDIR/integration/component/ test_minimal_ug_check.py --load -a tags=preupgrade
After Upgrade or any Changes done to the Setup, Verify that the existing CCP objects are not affected due to the external changes.
Execute:
nosetests --with-marvin --marvin-config=$CONFIG $BASEDIR/integration/component/ test_minimal_ug_check.py --load -a tags=postupgrade
Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
Antonio Fornie
Ian Southam
Leo Simons
Gaurav Aradhye
pritisarap12
SrikanteswaraRao Talluri
Ashutosh K
Daan Hoogland
Chandan Purushothama