cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: Removing deploy\load options from marvinplugin
Date Fri, 07 Feb 2014 23:26:21 GMT
Phew. Thanks for the tldr

On 2/7/14 3:53 AM, "Prasanna Santhanam" <tsp@apache.org> wrote:

>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