On Feb 7, 2014, at 6:26 PM, Chiradeep Vittal <[email protected]> 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" <[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 >> >
