cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <...@apache.org>
Subject Re: Removing deploy\load options from marvinplugin
Date Fri, 07 Feb 2014 11:53:58 GMT
tl;dr

i think your point 4 clarifies your change. remove --load and only run
tests unless --deploy is given. in the latter - do a deploy.


On Fri, Feb 07, 2014 at 11:30:19AM +0000, Santhosh Edukulla wrote:
> 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):
>         try:
>             self.config = configGenerator.getSetupConfig(self.configFile)
>         except:
>             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 log.name == "TestClient":
>                     testClientLogFile = log.file
>                 elif log.name == "TestCase":
>                     self.testCaseLogFile = log.file
>                 elif log.name == "TestResult":
>                     self.testResultLogFile = log.file
> 
>         testClientLogger = None
>         if testClientLogFile is not None:
>             testClientLogger = logging.getLogger("testclient.testengine.run")
>             fh = logging.FileHandler(testClientLogFile)
>             fh.setFormatter(logging.Formatter(
>                 "%(asctime)s - %(levelname)s - %(name)s\ - %(message)s")
>             )
>             testClientLogger.addHandler(fh)
>             testClientLogger.setLevel(logging.INFO)
>         self.testClientLogger = testClientLogger
>         self.testClient = \
>             cloudstackTestClient.\
>             cloudstackTestClient(mgtDetails,
>                                  dbSvrDetails,
>                                  logging=self.testClientLogger)
>                                  logger=self.tcRunLogger)
> 
>         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? 
> 
> Regards,
> Santhosh
> ________________________________________
> From: Prasanna Santhanam [tsp@apache.org]
> Sent: Friday, February 07, 2014 5:05 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Removing deploy\load options from marvinplugin
> 
> On Fri, Feb 07, 2014 at 09:36:49AM +0000, Santhosh Edukulla wrote:
> > From: Prasanna Santhanam [tsp@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

-- 
Prasanna.,

------------------------
Powered by BigRock.com


Mime
View raw message