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 [t...@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 [t...@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
