On Feb 7, 2014, at 6:26 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com>
wrote:
> Phew. Thanks for the tldr
Yes thanks, this was difficult to follow.
Definitely we want a deploy mechanism as simple as possible. I do have to say
that running 'nose' to just setup the configuration feels a bit
counterintuitive.
>
> On 2/7/14 3:53 AM, "Prasanna Santhanam" <t...@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 [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
>>
>> --
>> Prasanna.,
>>
>> ------------------------
>> Powered by BigRock.com
>>
>
