On Fri, Feb 07, 2014 at 09:36:49AM +0000, Santhosh Edukulla wrote: > 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.
What would the new behaviour be? nosetests only runs tests? and user has to do deploydatacenter before? > > 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? Can you answer this issue about logging you had raised? Didn't quite understand what you said. > > 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. I dont think you follow - users are doing the two steps because global settings are required before starting tests - and that requires a restart. So by retaining or removing, the users are not going to benefit from this. They'll use 4 different steps after this. How's that a simplification? 1. deploy cloudstack 2. deploydatacenter (done using nose earlier) 3. restart cloudstack 4. run tests (also done by nose earlier) Would including the restart within the plugin not make it a single step? What do you think? > > 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? Why would an IaaS need to leak information about itself? That is totally up to cloudstack. What we could do is query, that's easier to include than including an API within CS and later templatize it for reuse. Isn't repeating testbed configuration a good benefit? > > > > 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? true - it won't affect these specific areas. but the deployer is nice to have in the same tool that runs the tests. splitting it causes an additional headache of maintaining an additional module elsewhere in the repo. ------------------------ Powered by BigRock.com
