From dev-return-51634-apmail-cloudstack-dev-archive=cloudstack.apache.org@cloudstack.apache.org Fri Feb 7 07:25:35 2014 Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BDC0110946 for ; Fri, 7 Feb 2014 07:25:35 +0000 (UTC) Received: (qmail 12650 invoked by uid 500); 7 Feb 2014 07:25:34 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 12280 invoked by uid 500); 7 Feb 2014 07:25:33 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 12267 invoked by uid 99); 7 Feb 2014 07:25:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Feb 2014 07:25:32 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of santhosh.edukulla@citrix.com designates 103.14.252.240 as permitted sender) Received: from [103.14.252.240] (HELO SMTP.CITRIX.COM.AU) (103.14.252.240) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Feb 2014 07:25:28 +0000 X-IronPort-AV: E=Sophos;i="4.95,799,1384300800"; d="scan'208";a="2761636" Received: from sinaccessns.citrite.net (HELO SINPEX01CL01.citrite.net) ([10.151.60.9]) by sinpip01.citrite.net with ESMTP; 07 Feb 2014 07:25:04 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.69]) by SINPEX01CL01.citrite.net ([169.254.1.176]) with mapi id 14.02.0342.004; Fri, 7 Feb 2014 15:25:04 +0800 From: Santhosh Edukulla To: "dev@cloudstack.apache.org" Subject: RE: Removing deploy\load options from marvinplugin Thread-Topic: Removing deploy\load options from marvinplugin Thread-Index: Ac8jz/+WaA2a6l+xRz+G7XmXCoNqg///fNMAgACHnbU= Date: Fri, 7 Feb 2014 07:25:03 +0000 Message-ID: References: ,<20140207065438.GA5677@cloud-2.local> In-Reply-To: <20140207065438.GA5677@cloud-2.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.151.46.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-DLP: SIN1 X-Virus-Checked: Checked by ClamAV on apache.org 1. code restructuring ,definitely yes, it makes little neat and plugin does= not worry much about deploy altogether. Take an example of load option, i= t is little redundant i believe, if user passes the deploy flag, deploy sh= ould work and continue, if not passed should be treated as work with loadi= ng provided configuration and continue with no deploy. Even, for redeployin= g, user can still use deployDC, we don't exit cleanly in a way if deployDC = has an issue. The main reason behind this is providing some fine tuner log= ging for test modules not worrying about the logs when deployDC runs as par= t of marvinplugin. I have seen people currently run individual test suites = post deployDC separately. Is there a case explicitly for redploying with s= ame 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 m= akes to remove. Tying nosetests plugin to few things other than tests is= also little confusing.=20 2. Exporting a datacenter option would be an idea i believe best fits for c= loudstack, this i have raised in a mail thread earlier, where user can expo= rt or import configuration for a datacenter. So, that once exported can twe= ak few parameters and reimport. This will help create second datacenter wit= h similar configuration easy and store his existing configuration as well, = it will help other areas of automation as well. 3. Not sure, why we need to use marvinplugin for simulator deployDC? we ca= n 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 simulato= r. 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.=20 Regards, Santhosh ________________________________________ From: Prasanna Santhanam [tsp@apache.org] Sent: Friday, February 07, 2014 1:54 AM To: dev@cloudstack.apache.org Subject: Re: Removing deploy\load options from marvinplugin On Fri, Feb 07, 2014 at 06:44:07AM +0000, Santhosh Edukulla wrote: > Team, > > Do we have any issues if we remove dpeloy\load options from > marvinPlugin? Iam assuming users wanted to use deployDC can still > use other options available i.e.., deployDC etc. > > So, we just use marvinplugin to run only tests either list of suites > or individual suites? Let me know. > > EX: > 1. nosetests-2.7 -v --with-marvin > --marvin-config=3D/root/softwares/cscode/setup/dev/advanced.cfg -w > /tmp/checkfew/ -a tags=3Dadvanced :: Here, no load\deploy option. We > just use the config provided and run suites under the provided > directory. > > 2. nosetests-2.7 -v --with-marvin > --marvin-config=3D/root/softwares/cscode/setup/dev/advanced.cfg > /tmp/checkfew/test_x.py -a tags=3Dadvanced ::: Here, no load\deploy > option, we just use the config provided and run one single suite. > It's nice to have the ability to deploy and re-deploy the datacenter. In fact, it would be nicer to extended the deployer to also export the entire deployment model into json format. That way I can feed back the exported JSON and repeat my tests on a new deployment. What would happen to the deployer if marvin can only run test suites? This will potentially break few nice parts like - working on devcloud with a choice of configuration, work with the simulator as well. Any motivation besides code restructuring? -- Prasanna., ------------------------ Powered by BigRock.com