cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: Removing deploy\load options from marvinplugin
Date Sat, 08 Feb 2014 09:35:02 GMT

On Feb 7, 2014, at 6:26 PM, Chiradeep Vittal <Chiradeep.Vittal@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" <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