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 11:30:19 GMT
I believe we are deviating with too many notes here. Lets put things in perspective.

1. Initial point was to understand and take inputs to have and  work with marvinplugin using
less options for running, minimize options we have currently and can we remove few and work
with them? and i believe that's what you mentioned to have less options in earlier mail.

2. In the initial mail, it was mentioned that if there is a change, it will effect few areas
like devcloud\simulator, provided if there is a change, starting this thread is to know a
point of view and see the impact, that's what is to have clarified here. I see there is no
impact there in other areas mentioned, that does not mean we are agreeing for a  change.

3. Export\Import configuration from marvin\cloudstack is a separate issue for discussion,
i believe you can include it in a separate thread for now and discuss there. People can have
their say of having this facility or not. Regarding its a leak or not that's  a separate discussion
to have and how to design or implement again, that's nothing to do with options change we
mentioned. This will keep the current discussions easier to follow.

4. deploy VS load, in the earlier mail, i didn't mentioned to remove "deploy", i said only
load option. Lets see what load option is doing currently,  It does the below, which i believe
can still be possible with one "deploy" option.  Here, we are creating a client with configuration
provided. This is happening even with load option and as well as inside of deploy option .
I believe we can control this behavior with single deploy option. If deploy option is not
provided, then it works as though load option else deploy option of currently. Please let
me know where updating the global configuration is happening as part of current loadCfg option?

def loadCfg(self):
            self.config = configGenerator.getSetupConfig(self.configFile)
            raise cloudstackException.InvalidParameterException(
                "Failed to load config %s" % self.configFile)

        ''' Retrieving Management Server Connection Details '''
        mgtDetails = self.config.mgtSvr[0]
        ''' Retrieving Database Connection Details'''
        dbSvrDetails = self.config.dbSvr
        loggers = self.config.logger
        testClientLogFile = None
        self.testCaseLogFile = None
        self.testResultLogFile = None
        if loggers is not None and len(loggers) > 0:
            for log in loggers:
                if == "TestClient":
                    testClientLogFile = log.file
                elif == "TestCase":
                    self.testCaseLogFile = log.file
                elif == "TestResult":
                    self.testResultLogFile = log.file

        testClientLogger = None
        if testClientLogFile is not None:
            testClientLogger = logging.getLogger("")
            fh = logging.FileHandler(testClientLogFile)
                "%(asctime)s - %(levelname)s - %(name)s\ - %(message)s")
        self.testClientLogger = testClientLogger
        self.testClient = \

        if mgtDetails.apiKey is None:
            mgtDetails.apiKey, mgtDetails.securityKey = self.registerApiKey()there run a deployDC
with configuration provided and if not  
5. Also, its better if know where we are upading the other global configuration you mentioned
as part of load option? Here, its just creating the client based upon configuration provided.

6.  why deploying cloudstack is part of nose tests now and where we mentioned it is and make
it a 4 step process? We are anyways not doing it now as part of nosetests. We are adding one
more addition of restart CS, which is totally not required as part of nosetets.   Iam not
sure adding a restart simplifies and makes it little more complex. 

1. deploy cloudstack
2. deploydatacenter (done using nose earlier)
3. restart cloudstack
4. run tests (also done by nose earlier)
7. The reason for separation is to keep things simple. As a user, i can run below. The reason
i mentioned to separate deploy out of nose tests is we are not doing anything as such to report
a failure for bvt\regression etc for deployDC, we just exit without checks for deployDC. Also,
i mentioned the current flow as an eample, where we are using explicit deployDC, followed
by tests using nose plugin. If we have references where we are using it in both flows then
we can think of it, let us know?

1. DeployDC
2. Run test cases with nose tests.

8. The logging issue: What i meant was that we are doing some changes for logging. We are
providing log facility even there for deployDC. iam just trying to see there, as how to provide
logs deployDC separately from tests log, then the question derived to see cant we remove deployDC
from nosetests altogether? 

From: Prasanna Santhanam []
Sent: Friday, February 07, 2014 5:05 AM
Subject: Re: Removing deploy\load options from marvinplugin

On Fri, Feb 07, 2014 at 09:36:49AM +0000, Santhosh Edukulla wrote:
> From: Prasanna Santhanam []
> Sent: Friday, February 07, 2014 4:18 AM
> To:
> 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

View raw message