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