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
