Page History

...

1. Deploy Data Center Changes:
   
   
   • Separating TestClient from deploy Data Center: Earlier, testclient creation is also part of deployDatacenter. It is not part of this module responsibility to create test client in general. Now with this separation, testclient creation is  moved to cloudstackTestClient module and is responsible for creating and providing the test client for regression run. Added changes to both deployDataCenter and cloudstackTestClient. Fixed few misc issues and did some clean up here. Now deployDC will just take the required configuration and parameters and create the Data Center we needed. 
   • Delete Data Center:   There is no way to delete Deleting a created data center in current deploy Data Center is not possible. Added a new Delete Data Center Interface to delete the earlier created data center. If user wants to delete a Data Center created and recreate, deleting has to be manual earlier. With this change, he can delete a data center created and recreate. It will be useful at many places for testing to destroy and recreate with new settings etc.
     Usage: python deployDataCenter.py -i <path_to_marvin_config> -r<path_to_exported_create_dc_config>
   • Data Center creation as Transaction : At any given point of time during deploy data center, if an issue happens half way through, earlier created entries were still available in CS, it wont clean up i.e., data center is half created, Again, if tried to recreate , the earlier existing entries won't allowed to recreate. Now, data center works as transaction, either all entries are created as part of data center run or none, added a clean up to delete the half created data center.  
   • Export the created Data Center: Export the created Data Center as configuration, so that user can use it to further delete the data center with these exported entries etc. So, we can create, export,delete,recreate etc for our testing. This will  help in testing. With this change, once deploy Data Center finishes, it exports the created configuration to a path mentioned under input config file.
     
     
2. Parallel test runs against single management server :  This change will  help to run parallel test suites against multiple zones with each zone having one hypervisor. This will  help in cutting regression time, bvt time and explore few new bugs through running parallel suites against multiple zones. Earlier, there were hard coding for running test modules against a CS setup, under Test Suites, we had some hard coding values used to pickup first zone, first pod, first host,first template etc. So, even though we had multiple zones, hosts etc, it always used to pickup first zone,pod etc. With new changes added, we can now run automation for multiple hosts across zones on one management server driven by configuration.  So, a simple work flow as below:
   

...

https://issues.apache.org/jira/browse/CLOUDSTACK-5674

4. Misc Marvin Enhancements:  EX: SSH Library issues, other marvin issues for logging, as all related logs will be streamlined at one place for  the total run, other issues mentioned below were fixed. It will help in debugging failures post run. Now, for for the entire run, and for each test suite, we will see different logs viz., "run\results\exceptions+passfail " log all at one place. So, all logs separated by different category help resolve issues quickly. identify product issues vs test failures.  The log folder path once configured, will be used to provide logs separately for each test module.

...