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 4FA28F5C0 for ; Tue, 28 May 2013 20:31:52 +0000 (UTC) Received: (qmail 62802 invoked by uid 500); 28 May 2013 20:31:51 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 62763 invoked by uid 500); 28 May 2013 20:31:51 -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 62755 invoked by uid 99); 28 May 2013 20:31:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 May 2013 20:31:51 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of williamstevens@gmail.com designates 209.85.192.180 as permitted sender) Received: from [209.85.192.180] (HELO mail-pd0-f180.google.com) (209.85.192.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 May 2013 20:31:47 +0000 Received: by mail-pd0-f180.google.com with SMTP id 14so5605851pdc.25 for ; Tue, 28 May 2013 13:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=+4kYZegmK+wtmbDiksdzg1q+bSojuX7m5Eo0/gdEwmU=; b=rFZ79y+Ftk56hDArprPEYKOqhRn7BQGSlRmywAhHbt8n0A6ES+b/G7MNHoiNrO39vt JejpEq3Go0YCA6r9FEIsEvuWAdaNToIPv6/he2as7NYeZXqSFAjNS7Ac3p8OKI2vUUGT i92pQb/OfTi4wZUSmePzft3tP1ZJHiDF/F6eo4fPJv4niGxXBYk9xmJotqcmaPztiKdc 4FYRMLcQfgWtGJlPKfGqP4XMvc9Y01eAuMG8ZHMkwp3IWDs4+tb7njOUM5L1S32L1Ssx /1ukH9JRVy/rDfUIiLkaigJUYmzdslcHBshh2IKXBaosxCBf5d1uXjvEg2cNc9pIkY8g XpCQ== MIME-Version: 1.0 X-Received: by 10.66.120.164 with SMTP id ld4mr54686pab.187.1369773087125; Tue, 28 May 2013 13:31:27 -0700 (PDT) Sender: williamstevens@gmail.com Received: by 10.70.24.195 with HTTP; Tue, 28 May 2013 13:31:27 -0700 (PDT) In-Reply-To: <20130528180725.GZ11891@USLT-205755.sungardas.corp> References: <20130528180725.GZ11891@USLT-205755.sungardas.corp> Date: Tue, 28 May 2013 16:31:27 -0400 X-Google-Sender-Auth: jx97RcqfN90LA0S52qefROhMgJM Message-ID: Subject: Re: Palo Alto Firewall Integration - Review Process From: Will Stevens To: dev@cloudstack.apache.org Content-Type: multipart/alternative; boundary=047d7b0721ce47f40904ddcd267c X-Virus-Checked: Checked by ClamAV on apache.org --047d7b0721ce47f40904ddcd267c Content-Type: text/plain; charset=ISO-8859-1 Thanks for the reply Chip. Are there any docs / guides for the test functionality? On Tue, May 28, 2013 at 2:07 PM, Chip Childers wrote: > On Tue, May 28, 2013 at 01:32:48PM -0400, Will Stevens wrote: > > Hey All, > > I am getting close to finishing up this integration, so I want to make > sure > > I understand the process and what is required for submitting my code for > > review. > > > > I have read this and am comfortable with its content: > > http://cloudstack.apache.org/develop/non-committer.html > > > > You can check out more details regarding this integration here: > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration > > > > Please let me know if you feel I am missing anything on that page. That > is > > still a work in progress, but it does cover the functionality being added > > pretty well. The screenshots are not complete yet, but they are at about > > 90% right now. > > > > On that page I have linked a public repo which has a recent working > version > > of the code (not feature complete yet and still needs some clean up). > > Thanks for doing that! > > > > > Here are the questions that I have about the process: > > - Do I need to include tests for this code? If so, is this documented > > somewhere? Since this is an integration with an external device, how > would > > tests be written to pass without actually connecting to a device? > > 2 test types: > > 1 - unit tests using a mocking framework are needed for non-trivial > logic (complex methods) > > 2 - integration tests using the marvin framework are the best method of > providing automated testing of a specific integration. However, you > might want to see if your functionality is *already* covered in the test > suite. If you are only implementing a driver for a specific technology, > it might be easy to just play a set of tests against an environment with > that device enabled. > > > - There is a small limitation in core which did not have any dependancies > > which I have fixed (Sheng and I have discussed this briefly). > Basically, I > > added support for multiple networks per account when the source nat type > is > > 'per account' with an external device. Question: Should I be submitting > > two patches; one which only addresses this core fix (about 5 lines of > code) > > and one which addresses the addition of the palo_alto network plugin? > Or, > > should I submit it all as one patch? > > Best to do it as 2. Note in the new feature patch that it relies on the > "core" patch. > > > - Since this is an integration with a 3rd party product; should I setup > > a publicly accessible system where the functionality can be reviewed, or > > should I work with Palo Alto to get demo licenses for their VM firewall > > appliances and provide the reviewers licences to test the functionality? > I > > am not sure how this aspect should work, so let me know what the best > > approach would be. > > We don't have a good model for this. Your demo license proposal sounds > interesting though. Perhaps that's the model we *should* be using > whenever possible? > > > > > I think thats it. Please let me know if something is not clear or if you > > feel I need to flush out some of the details somewhere. > > > > Thanks, > > > > Will > --047d7b0721ce47f40904ddcd267c--