Phew. Thanks for the tldr
On 2/7/14 3:53 AM, "Prasanna Santhanam" <[email protected]> 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 [[email protected]]
>> Sent: Friday, February 07, 2014 5:05 AM
>> To: [email protected]
>> Subject: Re: Removing deploy\load options from marvinplugin
>>
>> On Fri, Feb 07, 2014 at 09:36:49AM +0000, Santhosh Edukulla wrote:
>> > From: Prasanna Santhanam [[email protected]]
>> > Sent: Friday, February 07, 2014 4:18 AM
>> > To: [email protected]
>> > 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
>
