cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santhosh Edukulla <>
Subject RE: Removing deploy\load options from marvinplugin
Date Fri, 07 Feb 2014 09:36:49 GMT

From: Prasanna Santhanam []
Sent: Friday, February 07, 2014 4:18 AM
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

> 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?

View raw message