CIL
________________________________________ From: Prasanna Santhanam [t...@apache.org] Sent: Friday, February 07, 2014 4:18 AM To: dev@cloudstack.apache.org Subject: Re: Removing deploy\load options from marvinplugin On Fri, Feb 07, 2014 at 07:25:03AM +0000, Santhosh Edukulla wrote: > 1. code restructuring ,definitely yes, it makes little neat and > plugin does not worry much about deploy altogether. Take an example > of load option, it is little redundant i believe, if user passes the > deploy flag, deploy should work and continue, if not passed should > be treated as work with loading provided configuration and continue > with no deploy. May be make the plugin smarter and include less options then? [Santhosh] : I will remove load option. > Even, for redeploying, user can still use deployDC, > we don't exit cleanly in a way if deployDC has an issue. Again - feels like an area of improvement for deploydatacenter > reason behind this is providing some fine tuner logging for test > modules not worrying about the logs when deployDC runs as part of > marvinplugin. I have seen people currently run individual test > suites post deployDC separately. deploydatacenter failures could use logging. what is fine-tuned logging? our test modules have their own logs correct? may be the logger configuration should be outside the deployer, is this what you mean? > Is there a case explicitly for > redploying with same configuration and i believe if so it breaks, if > its a new cofiguration then its a new deploy altogether. To make > plugin init, start cleaner this makes to remove. Tying nosetests > plugin to few things other than tests is also little confusing. A bit of history - the reason the load option is present is because you can't start running the tests immediately after deploying your cloud. This actually sucks. The reason for the two step - deploy and run tests is because certain configurations in the global settings need a restart of the cloudstack service. The original test runner was meant to run tests immediately after deploy. Hence, when load is not specified, it starts running tests immediately. [Santhosh] : Its still little unclear here, using load explicitly as we dont have a sequence maintained for restarting cs and we are loading from config. > 2. Exporting a datacenter option would be an idea i believe best > fits for cloudstack, this i have raised in a mail thread earlier, > where user can export or import configuration for a datacenter. So, > that once exported can tweak few parameters and reimport. This will > help create second datacenter with similar configuration easy and > store his existing configuration as well, it will help other areas > of automation as well. Right - there's a JIRA at CLOUDSTACK-4590 - I see the deployer being part of marvin for this reason. Different configurations, same tests. Same configuration, different tests. [Santhosh] : Frankly, i dont see a case to export the configuration, we are creating deployDC using a config signifies we have a config, why export the same using marvin again? > > 3. Not sure, why we need to use marvinplugin for simulator deployDC? > we can still use deployDC and run tests against the similator. > Currently, also i have seen we use unittest load and run as part of > mvn profile for simulator. Any places where marvinplugin is used for > simulator? For devcloud, do we run nosetests using marvinplugin or > run deployDC separately, if its a case we can remove there as well. > marvinplugin is only a console entry point for nose really. it is basically calling in deploydatacenter. just a nice option. however, i don't see how it hinders anything. hence my surprise at removing it. [Santhosh]: Again it seems we are not using marvinplugin here, so in a way it wont these areas, to double confirm? -- Prasanna.,
