Return-Path: X-Original-To: apmail-cloudstack-issues-archive@www.apache.org Delivered-To: apmail-cloudstack-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9310010948 for ; Mon, 28 Oct 2013 06:37:21 +0000 (UTC) Received: (qmail 57514 invoked by uid 500); 28 Oct 2013 06:37:20 -0000 Delivered-To: apmail-cloudstack-issues-archive@cloudstack.apache.org Received: (qmail 57467 invoked by uid 500); 28 Oct 2013 06:37:20 -0000 Mailing-List: contact issues-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 issues@cloudstack.apache.org Received: (qmail 57450 invoked by uid 99); 28 Oct 2013 06:37:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Oct 2013 06:37:20 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [208.91.199.217] (HELO us2.outbound.mailhostbox.com) (208.91.199.217) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Oct 2013 06:37:15 +0000 Received: from localhost (ec2-75-101-146-23.compute-1.amazonaws.com [75.101.146.23]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: tsp@v0g0n.org) by us2.outbound.mailhostbox.com (Postfix) with ESMTPSA id C54F126809D; Mon, 28 Oct 2013 06:36:51 +0000 (GMT) Date: Mon, 28 Oct 2013 12:06:48 +0530 From: Prasanna Santhanam To: dev@cloudstack.apache.org Cc: "issues@cloudstack.apache.org" Subject: Re: [DISCUSS] (CLOUDSTACK-4971) Verifying Test Beds : prerequisites for launching tests Message-ID: <20131028063648.GA3972@cloud-2.local> Mail-Followup-To: dev@cloudstack.apache.org, "issues@cloudstack.apache.org" References: <20131028061519.GA3424@cloud-2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-CTCH-RefID: str=0001.0A020202.526E0606.003F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: tsp@apache.org X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.16.214.9 X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Oct 28, 2013 at 06:24:05AM +0000, Santhosh Edukulla wrote: > Here, we mean test setup, not marvin setup ( or setup.py ) . Sure - I understand that :). Marvin's setup is only a build+packaging file. I should've been clear - when I say deployment scripts those are the cloud-autodeploy scripts that setup the testbed. Marvin's dumb in that respect and only comes in when cloudstack is configured and tests are launched. > > Each test has their own dependency, we are having > setup,flow,teardown for test module. By below content of bug > description, we mean verifying the test dependencies under setup > class of a test feature or module not the marvin setup. The test > feature or module setup can take care to verify these dependencies > and exit with better log and reporting as against reporting the test > cases as failures. Right - so you're saying you'll change the tests. But as I mentioned with 'netaddr' it's the problem of the python environment running the test. The test is free to import 'netaddr' but not install it. > > Some dependencies at marvin setup can be verified, but the below > purpose is to ensure test dependencies are met before running tests. > The goal is to make less or zero % test script errors, against > genuine product bugs as failures. > Okay - by 'met before running' you mean during deployment or before test launch? Or as part of the setUpClass? If it is part of the setUpClass. Isn't that just a guideline to the test case writer? > Santhosh > ________________________________________ > From: Prasanna Santhanam [tsp@apache.org] > Sent: Monday, October 28, 2013 2:15 AM > To: dev@cloudstack.apache.org > Cc: issues@cloudstack.apache.org > Subject: [DISCUSS] (CLOUDSTACK-4971) Verifying Test Beds : prerequisites for launching tests > > I like the concept of a health check before launching tests. But it's > a difficult distinction to make whether to run a specific test because > its required hardware component/external dependency is not > available/not ready in the deployment OR have the test ensure that the > deployment is suitable for its run. > > So our current health check only ensures two things > - SystemVMs are up and running > - Default Templates are 'Ready' in the system > > Take the example of LDAP here that you quoted. In such a case I'd > prefer that the test itself check for the deployment guarantees > without pushing that to the framework or the deployment scripts to > decipher. > > There is a counter case - some tests use the netaddr module to do > subnet arithmetic. For these to run we need to ensure the virtualenv > under which the test module runs contains netaddr. This is something > that can be ensured by the deployment scripts. > > So this is a question of guidelines to test authors on what to expect > and what not to expect when writing a test. Also how to have the > dependencies added automatically before the test gets executed. I > don't see a one-size-fits-all solution. > > On Mon, Oct 28, 2013 at 05:49:39AM +0000, Santhosh Kumar Edukulla (JIRA) wrote: > > Santhosh Kumar Edukulla created CLOUDSTACK-4971: > > > > 1, Currently test scripts are running despite the test setup has > > issues. EX: In one of the test scenario, where ldap server was down, > > then test suite depending upon them was still running. > > > > 2, Ideally, the setup should check for these dependencies before > > running the test script and exit wherever possible with proper log > > and reporting . > > > > 3, We may not be able to cover all setup issues, but the purpose of > > setup is also to check for its existence and dependencies. If > > scripts depending upon particular server conditions, should have a > > proper setup verifying the server existence before proceeding > > further. > > > > 4, I believe running test cases when setup is down is also not > > idealistic. > > > > 5. Purpose is to reduce script errors vs failures due to product > > bugs. > > > > 6. Logging this bug to track the setup issue cases or script > > failures. > > > -- > Prasanna., > > ------------------------ > Powered by BigRock.com -- Prasanna., ------------------------ Powered by BigRock.com