Re: [Merge] Palo Alto Networks firewall integration to master

2014-02-03 Thread Will Stevens
Sorry, I thought I had responded to you on this, but I just realized I
hadn't.  I tested all my functionality a couple days ago and everything is
working so this issue is resolved.

Thanks...


On Wed, Jan 15, 2014 at 6:14 PM, Animesh Chaturvedi 
animesh.chaturv...@citrix.com wrote:

 Will

 I was doing some housekeeping for release and noticed that the  JIRA
 ticket [5] was unresolved and not tagged for 4.3. I have updated it as
 resolved and tagged for 4.3. Let me know if this is not correct

 Animesh

 -Original Message-
 From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
 Behalf Of Will Stevens
 Sent: Thursday, October 31, 2013 1:51 PM
 To: dev@cloudstack.apache.org
 Subject: [Merge] Palo Alto Networks firewall integration to master

 Hi,

 I would like to merge support for Palo Alto Network's firewall appliances
 to the master branch.  Development for this has been done by Will Stevens
 at CloudOps on branch [1].

 There was an introduction [2], a proposal [3], and a discussion [4] on the
 mailing list regarding this feature.

 Checklist:
 Jira ticket for the feature is here [5].
 The FS can be found at [6].
 Unit tests for the feature are available at [7] and [8].  I have developed
 the unit tests with a flag to output additional detail in the console [9].
  Here is the result of the tests without detail [10] and here is the
 result of the tests with detail [11].

 This plugin communicates to the Palo Alto Networks firewall appliances
 through an API documented at [12] with a training manual [13].
 This plugin depends on a modification to core to remove a limitation which
 was discussed here [14], with this jira issue [15] and has been approved
 here [16].
 This plugin is being reviewed at [17] according to this patch [18].

 There are no 3rd party libraries needed for this plugin, however it does
 depend on a 3rd party API [12][13] to orchestrate the configuration on the
 appliance.  The plugin is currently being built via the 'nonoss' flag.  It
 should be moved into either the 'noredist' or core because it appears that
 'nonoss' will be going away [19] and 'noredist' has been merged [20].  I
 would appreciate input on which build this should be put into given its
 interaction with an 3rd party appliance.

 Here are the slides for a presentation [21] given about this integration
 at the CloudStack Collaboration Conference in Santa Clara, CA.

 [1] https://github.com/cloudops/cs_palo_alto/tree/palo_alto
 [2]

 http://markmail.org/message/hukydzwkec3dwuxq?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
 [3]

 http://markmail.org/message/odbg2icft7esj3ut?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
 [4]

 http://markmail.org/message/n5276i4hfh7ek57o?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
 [5] https://issues.apache.org/jira/browse/CLOUDSTACK-1275
 [6]

 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
 [7]

 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java
 [8]

 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/MockablePaloAltoResource.java
 [9]

 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java#L156
 [10]

 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_without_logging.txt?version=1modificationDate=1383248404474
 [11]

 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_with_logging.txt?version=1modificationDate=1383248432061
 [12]

 https://cwiki.apache.org/confluence/download/attachments/30753712/XML-API-5-1.0-RevA.pdf?version=1modificationDate=1366305634000
 [13]

 https://cwiki.apache.org/confluence/download/attachments/30753712/XML_API_Training.pdf?version=1modificationDate=1366305635000
 [14]

 http://markmail.org/message/374hyn7ko6zrb2cf?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+supported+source+nat+types
 [15] https://issues.apache.org/jira/browse/CLOUDSTACK-4991
 [16] https://reviews.apache.org/r/15047/
 [17] https://reviews.apache.org/r/15050/
 [18] https://reviews.apache.org/r/15050/diff/
 [19]

 http://markmail.org/message/37qcg4lgudmf57ws?q=DISCUSS%5D+rename+nonoss+to+noredist
 [20]

 http://markmail.org/message/zqkiuod5qabcyra6?q=%5BMERGE%5D+changing+nonoss+to+noredist
 [21]

 https://cwiki.apache.org/confluence/download/attachments/30753712/CS_PA_Integration.pptx?version=1modificationDate=1383250830719

 Cheers,

 Will



RE: [Merge] Palo Alto Networks firewall integration to master

2014-01-15 Thread Animesh Chaturvedi
Will

I was doing some housekeeping for release and noticed that the  JIRA ticket [5] 
was unresolved and not tagged for 4.3. I have updated it as resolved and tagged 
for 4.3. Let me know if this is not correct

Animesh

-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: Thursday, October 31, 2013 1:51 PM
To: dev@cloudstack.apache.org
Subject: [Merge] Palo Alto Networks firewall integration to master

Hi,

I would like to merge support for Palo Alto Network's firewall appliances to 
the master branch.  Development for this has been done by Will Stevens at 
CloudOps on branch [1].

There was an introduction [2], a proposal [3], and a discussion [4] on the 
mailing list regarding this feature.

Checklist:
Jira ticket for the feature is here [5].
The FS can be found at [6].
Unit tests for the feature are available at [7] and [8].  I have developed the 
unit tests with a flag to output additional detail in the console [9].
 Here is the result of the tests without detail [10] and here is the result of 
the tests with detail [11].

This plugin communicates to the Palo Alto Networks firewall appliances through 
an API documented at [12] with a training manual [13].
This plugin depends on a modification to core to remove a limitation which was 
discussed here [14], with this jira issue [15] and has been approved here [16].
This plugin is being reviewed at [17] according to this patch [18].

There are no 3rd party libraries needed for this plugin, however it does depend 
on a 3rd party API [12][13] to orchestrate the configuration on the appliance.  
The plugin is currently being built via the 'nonoss' flag.  It should be moved 
into either the 'noredist' or core because it appears that 'nonoss' will be 
going away [19] and 'noredist' has been merged [20].  I would appreciate input 
on which build this should be put into given its interaction with an 3rd party 
appliance.

Here are the slides for a presentation [21] given about this integration at the 
CloudStack Collaboration Conference in Santa Clara, CA.

[1] https://github.com/cloudops/cs_palo_alto/tree/palo_alto
[2]
http://markmail.org/message/hukydzwkec3dwuxq?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
[3]
http://markmail.org/message/odbg2icft7esj3ut?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
[4]
http://markmail.org/message/n5276i4hfh7ek57o?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
[5] https://issues.apache.org/jira/browse/CLOUDSTACK-1275
[6]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
[7]
https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java
[8]
https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/MockablePaloAltoResource.java
[9]
https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java#L156
[10]
https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_without_logging.txt?version=1modificationDate=1383248404474
[11]
https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_with_logging.txt?version=1modificationDate=1383248432061
[12]
https://cwiki.apache.org/confluence/download/attachments/30753712/XML-API-5-1.0-RevA.pdf?version=1modificationDate=1366305634000
[13]
https://cwiki.apache.org/confluence/download/attachments/30753712/XML_API_Training.pdf?version=1modificationDate=1366305635000
[14]
http://markmail.org/message/374hyn7ko6zrb2cf?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+supported+source+nat+types
[15] https://issues.apache.org/jira/browse/CLOUDSTACK-4991
[16] https://reviews.apache.org/r/15047/
[17] https://reviews.apache.org/r/15050/
[18] https://reviews.apache.org/r/15050/diff/
[19]
http://markmail.org/message/37qcg4lgudmf57ws?q=DISCUSS%5D+rename+nonoss+to+noredist
[20]
http://markmail.org/message/zqkiuod5qabcyra6?q=%5BMERGE%5D+changing+nonoss+to+noredist
[21]
https://cwiki.apache.org/confluence/download/attachments/30753712/CS_PA_Integration.pptx?version=1modificationDate=1383250830719

Cheers,

Will


RE: [Merge] Palo Alto Networks firewall integration to master

2013-11-07 Thread Animesh Chaturvedi
Fails RAT on 
plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientWrapper.java


 -Original Message-
 From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
 Behalf Of Will Stevens
 Sent: Wednesday, November 06, 2013 10:15 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [Merge] Palo Alto Networks firewall integration to master
 
 Great!  Thank you Sheng...
 
 
 On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang sh...@yasker.org wrote:
 
  Looks good to me.
 
  Applied to MASTER branch. Thanks!
 
  --Sheng
 
 
  On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens wstev...@cloudops.com
  wrote:
 
   @Sheng:  This should be ready to go now.  I built the patch from
  tonight's
   master and I included a more detailed commit message as you
 requested.
   Let
   me know if you have any questions/problems...
  
   @David:  As per this discussion (and a previous one [1]), I have
   moved
  this
   code from being built with the depreciated 'nonoss' flag to core
   since it does not depend on any 3rd party libraries at build or
 runtime.
  
   Cheers,
  
   Will
  
   [1]
  
  
  http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
  ubator%2Ecloudstack-%2A+Palo+Alto
  
  
   On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
   wstev...@cloudops.com
   wrote:
  
Thanks for that David.  You are absolutely correct, this plugin
has no dependencies on any 3rd party code at build or runtime.
Everything the plugin requires is built into the plugin.  I was
unclear if its
   dependance
on a 3rd party API and appliance to be functional was relevant.
   
I think you are right.  I think it should probably be in the core
  build.
 I will make that change when I merge in the latest master for
Sheng
  and
rebuild the patch.
   
Thanks,
   
Will
   
   
On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us
 wrote:
   
So perhaps a bit of history.
   
nonoss/noredist is for targets that aren't built 'by default'
 (e.g.
you must explicitly turn them on). We do this because the ASF
wants the default build to be truly unencumbered and where there
are dependencies on non-open source, or non-Apache compatible
code, we typically turn them off. In example: historically,
Netscaler libraries were not open source, and we had a dependency
on those libraries, so we placed the netscaler plugin into the
nonoss. Since then the netscaler libraries have been open
sourced, and we could move those out of noredist.
   
So - is there third party code that you have as a build or
runtime dependency? If so what is the license for that third
party code? (My really fast perusal didn't catch anything that
was immediately
troubling)
   
--David
   
On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens
wstev...@cloudops.com
wrote:
 Its dependence on a third party API and appliance, similar to
 the
  srx
and
 netscaler. I am not convinced it should be in noredist, but I
 was
following
 the same model as other similar plugins.  Feedback on this
 would be helpful.

 Ws

 On Tuesday, November 5, 2013, David Nalley wrote:

 On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
  wstev...@cloudops.com
javascript:;
 wrote:
  Sheng, I will rebuild the patch for the latest master.  The
  latest
master
  has depreciated the 'nonoss' flag in favour of 'noredist'. I
  was
building
  in nonoss previously. I am guessing I should use the
  noredist
  flag
now?
 

 Will - what is causing this to be noredist/nonoss? My quick
 perusal
   of
 your patch didn't surface anything that would push it into
 that category.

 --David

   
   
   
  
 


Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-07 Thread Sheng Yang
Fixed.

--Sheng


On Thu, Nov 7, 2013 at 10:23 AM, Animesh Chaturvedi 
animesh.chaturv...@citrix.com wrote:

 Fails RAT on
 plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientWrapper.java


  -Original Message-
  From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
  Behalf Of Will Stevens
  Sent: Wednesday, November 06, 2013 10:15 AM
  To: dev@cloudstack.apache.org
  Subject: Re: [Merge] Palo Alto Networks firewall integration to master
 
  Great!  Thank you Sheng...
 
 
  On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang sh...@yasker.org wrote:
 
   Looks good to me.
  
   Applied to MASTER branch. Thanks!
  
   --Sheng
  
  
   On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens wstev...@cloudops.com
   wrote:
  
@Sheng:  This should be ready to go now.  I built the patch from
   tonight's
master and I included a more detailed commit message as you
  requested.
Let
me know if you have any questions/problems...
   
@David:  As per this discussion (and a previous one [1]), I have
moved
   this
code from being built with the depreciated 'nonoss' flag to core
since it does not depend on any 3rd party libraries at build or
  runtime.
   
Cheers,
   
Will
   
[1]
   
   
   http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
   ubator%2Ecloudstack-%2A+Palo+Alto
   
   
On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
wstev...@cloudops.com
wrote:
   
 Thanks for that David.  You are absolutely correct, this plugin
 has no dependencies on any 3rd party code at build or runtime.
 Everything the plugin requires is built into the plugin.  I was
 unclear if its
dependance
 on a 3rd party API and appliance to be functional was relevant.

 I think you are right.  I think it should probably be in the core
   build.
  I will make that change when I merge in the latest master for
 Sheng
   and
 rebuild the patch.

 Thanks,

 Will


 On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us
  wrote:

 So perhaps a bit of history.

 nonoss/noredist is for targets that aren't built 'by default'
  (e.g.
 you must explicitly turn them on). We do this because the ASF
 wants the default build to be truly unencumbered and where there
 are dependencies on non-open source, or non-Apache compatible
 code, we typically turn them off. In example: historically,
 Netscaler libraries were not open source, and we had a dependency
 on those libraries, so we placed the netscaler plugin into the
 nonoss. Since then the netscaler libraries have been open
 sourced, and we could move those out of noredist.

 So - is there third party code that you have as a build or
 runtime dependency? If so what is the license for that third
 party code? (My really fast perusal didn't catch anything that
 was immediately
 troubling)

 --David

 On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens
 wstev...@cloudops.com
 wrote:
  Its dependence on a third party API and appliance, similar to
  the
   srx
 and
  netscaler. I am not convinced it should be in noredist, but I
  was
 following
  the same model as other similar plugins.  Feedback on this
  would be helpful.
 
  Ws
 
  On Tuesday, November 5, 2013, David Nalley wrote:
 
  On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
   wstev...@cloudops.com
 javascript:;
  wrote:
   Sheng, I will rebuild the patch for the latest master.  The
   latest
 master
   has depreciated the 'nonoss' flag in favour of 'noredist'. I
   was
 building
   in nonoss previously. I am guessing I should use the
   noredist
   flag
 now?
  
 
  Will - what is causing this to be noredist/nonoss? My quick
  perusal
of
  your patch didn't surface anything that would push it into
  that category.
 
  --David
 



   
  



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-07 Thread Will Stevens
Just so I know, can you explain what it means to 'Fail RAT'?  Thx...


On Thu, Nov 7, 2013 at 1:46 PM, Sheng Yang sh...@yasker.org wrote:

 Fixed.

 --Sheng


 On Thu, Nov 7, 2013 at 10:23 AM, Animesh Chaturvedi 
 animesh.chaturv...@citrix.com wrote:

  Fails RAT on
 
 plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientWrapper.java
 
 
   -Original Message-
   From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
   Behalf Of Will Stevens
   Sent: Wednesday, November 06, 2013 10:15 AM
   To: dev@cloudstack.apache.org
   Subject: Re: [Merge] Palo Alto Networks firewall integration to master
  
   Great!  Thank you Sheng...
  
  
   On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang sh...@yasker.org wrote:
  
Looks good to me.
   
Applied to MASTER branch. Thanks!
   
--Sheng
   
   
On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens wstev...@cloudops.com
wrote:
   
 @Sheng:  This should be ready to go now.  I built the patch from
tonight's
 master and I included a more detailed commit message as you
   requested.
 Let
 me know if you have any questions/problems...

 @David:  As per this discussion (and a previous one [1]), I have
 moved
this
 code from being built with the depreciated 'nonoss' flag to core
 since it does not depend on any 3rd party libraries at build or
   runtime.

 Cheers,

 Will

 [1]


   
 http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
ubator%2Ecloudstack-%2A+Palo+Alto


 On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
 wstev...@cloudops.com
 wrote:

  Thanks for that David.  You are absolutely correct, this plugin
  has no dependencies on any 3rd party code at build or runtime.
  Everything the plugin requires is built into the plugin.  I was
  unclear if its
 dependance
  on a 3rd party API and appliance to be functional was relevant.
 
  I think you are right.  I think it should probably be in the core
build.
   I will make that change when I merge in the latest master for
  Sheng
and
  rebuild the patch.
 
  Thanks,
 
  Will
 
 
  On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us
   wrote:
 
  So perhaps a bit of history.
 
  nonoss/noredist is for targets that aren't built 'by default'
   (e.g.
  you must explicitly turn them on). We do this because the ASF
  wants the default build to be truly unencumbered and where there
  are dependencies on non-open source, or non-Apache compatible
  code, we typically turn them off. In example: historically,
  Netscaler libraries were not open source, and we had a
 dependency
  on those libraries, so we placed the netscaler plugin into the
  nonoss. Since then the netscaler libraries have been open
  sourced, and we could move those out of noredist.
 
  So - is there third party code that you have as a build or
  runtime dependency? If so what is the license for that third
  party code? (My really fast perusal didn't catch anything that
  was immediately
  troubling)
 
  --David
 
  On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens
  wstev...@cloudops.com
  wrote:
   Its dependence on a third party API and appliance, similar to
   the
srx
  and
   netscaler. I am not convinced it should be in noredist, but I
   was
  following
   the same model as other similar plugins.  Feedback on this
   would be helpful.
  
   Ws
  
   On Tuesday, November 5, 2013, David Nalley wrote:
  
   On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
wstev...@cloudops.com
  javascript:;
   wrote:
Sheng, I will rebuild the patch for the latest master.  The
latest
  master
has depreciated the 'nonoss' flag in favour of 'noredist'.
 I
was
  building
in nonoss previously. I am guessing I should use the
noredist
flag
  now?
   
  
   Will - what is causing this to be noredist/nonoss? My quick
   perusal
 of
   your patch didn't surface anything that would push it into
   that category.
  
   --David
  
 
 
 

   
 



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-07 Thread Sheng Yang
Oh, that means something wrong with the license header of the file(header
missing in this case).

http://creadur.apache.org/rat/

--Sheng


On Thu, Nov 7, 2013 at 10:50 AM, Will Stevens wstev...@cloudops.com wrote:

 Just so I know, can you explain what it means to 'Fail RAT'?  Thx...


 On Thu, Nov 7, 2013 at 1:46 PM, Sheng Yang sh...@yasker.org wrote:

  Fixed.
 
  --Sheng
 
 
  On Thu, Nov 7, 2013 at 10:23 AM, Animesh Chaturvedi 
  animesh.chaturv...@citrix.com wrote:
 
   Fails RAT on
  
 
 plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientWrapper.java
  
  
-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
Behalf Of Will Stevens
Sent: Wednesday, November 06, 2013 10:15 AM
To: dev@cloudstack.apache.org
Subject: Re: [Merge] Palo Alto Networks firewall integration to
 master
   
Great!  Thank you Sheng...
   
   
On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang sh...@yasker.org wrote:
   
 Looks good to me.

 Applied to MASTER branch. Thanks!

 --Sheng


 On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens 
 wstev...@cloudops.com
 wrote:

  @Sheng:  This should be ready to go now.  I built the patch from
 tonight's
  master and I included a more detailed commit message as you
requested.
  Let
  me know if you have any questions/problems...
 
  @David:  As per this discussion (and a previous one [1]), I have
  moved
 this
  code from being built with the depreciated 'nonoss' flag to core
  since it does not depend on any 3rd party libraries at build or
runtime.
 
  Cheers,
 
  Will
 
  [1]
 
 

  http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
 ubator%2Ecloudstack-%2A+Palo+Alto
 
 
  On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
  wstev...@cloudops.com
  wrote:
 
   Thanks for that David.  You are absolutely correct, this plugin
   has no dependencies on any 3rd party code at build or runtime.
   Everything the plugin requires is built into the plugin.  I was
   unclear if its
  dependance
   on a 3rd party API and appliance to be functional was relevant.
  
   I think you are right.  I think it should probably be in the
 core
 build.
I will make that change when I merge in the latest master for
   Sheng
 and
   rebuild the patch.
  
   Thanks,
  
   Will
  
  
   On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us
wrote:
  
   So perhaps a bit of history.
  
   nonoss/noredist is for targets that aren't built 'by default'
(e.g.
   you must explicitly turn them on). We do this because the ASF
   wants the default build to be truly unencumbered and where
 there
   are dependencies on non-open source, or non-Apache compatible
   code, we typically turn them off. In example: historically,
   Netscaler libraries were not open source, and we had a
  dependency
   on those libraries, so we placed the netscaler plugin into the
   nonoss. Since then the netscaler libraries have been open
   sourced, and we could move those out of noredist.
  
   So - is there third party code that you have as a build or
   runtime dependency? If so what is the license for that third
   party code? (My really fast perusal didn't catch anything that
   was immediately
   troubling)
  
   --David
  
   On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens
   wstev...@cloudops.com
   wrote:
Its dependence on a third party API and appliance, similar
 to
the
 srx
   and
netscaler. I am not convinced it should be in noredist, but
 I
was
   following
the same model as other similar plugins.  Feedback on this
would be helpful.
   
Ws
   
On Tuesday, November 5, 2013, David Nalley wrote:
   
On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
 wstev...@cloudops.com
   javascript:;
wrote:
 Sheng, I will rebuild the patch for the latest master.
  The
 latest
   master
 has depreciated the 'nonoss' flag in favour of
 'noredist'.
  I
 was
   building
 in nonoss previously. I am guessing I should use the
 noredist
 flag
   now?

   
Will - what is causing this to be noredist/nonoss? My quick
perusal
  of
your patch didn't surface anything that would push it into
that category.
   
--David
   
  
  
  
 

  
 



RE: [Merge] Palo Alto Networks firewall integration to master

2013-11-07 Thread Animesh Chaturvedi
RAT is release audit tool and checks for missing license headers. You can run 
it as below


mvn --projects='org.apache.cloudstack:cloudstack' 
org.apache.rat:apache-rat-plugin:0.8:check


The build should FAIL if there are any non-compliant files that are not 
specifically excluded from the ASF license header requirement. You can 
optionally review the target/rat.txt file after the run completes. 


 -Original Message-
 From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
 Behalf Of Will Stevens
 Sent: Thursday, November 07, 2013 10:51 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [Merge] Palo Alto Networks firewall integration to master
 
 Just so I know, can you explain what it means to 'Fail RAT'?  Thx...
 
 
 On Thu, Nov 7, 2013 at 1:46 PM, Sheng Yang sh...@yasker.org wrote:
 
  Fixed.
 
  --Sheng
 
 
  On Thu, Nov 7, 2013 at 10:23 AM, Animesh Chaturvedi 
  animesh.chaturv...@citrix.com wrote:
 
   Fails RAT on
  
  plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpCli
  entWrapper.java
  
  
-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com]
On Behalf Of Will Stevens
Sent: Wednesday, November 06, 2013 10:15 AM
To: dev@cloudstack.apache.org
Subject: Re: [Merge] Palo Alto Networks firewall integration to
master
   
Great!  Thank you Sheng...
   
   
On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang sh...@yasker.org
 wrote:
   
 Looks good to me.

 Applied to MASTER branch. Thanks!

 --Sheng


 On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens
 wstev...@cloudops.com
 wrote:

  @Sheng:  This should be ready to go now.  I built the patch
  from
 tonight's
  master and I included a more detailed commit message as you
requested.
  Let
  me know if you have any questions/problems...
 
  @David:  As per this discussion (and a previous one [1]), I
  have moved
 this
  code from being built with the depreciated 'nonoss' flag to
  core since it does not depend on any 3rd party libraries at
  build or
runtime.
 
  Cheers,
 
  Will
 
  [1]
 
 

  http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
 ubator%2Ecloudstack-%2A+Palo+Alto
 
 
  On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
  wstev...@cloudops.com
  wrote:
 
   Thanks for that David.  You are absolutely correct, this
   plugin has no dependencies on any 3rd party code at build or
 runtime.
   Everything the plugin requires is built into the plugin.  I
   was unclear if its
  dependance
   on a 3rd party API and appliance to be functional was
 relevant.
  
   I think you are right.  I think it should probably be in the
   core
 build.
I will make that change when I merge in the latest master
   for Sheng
 and
   rebuild the patch.
  
   Thanks,
  
   Will
  
  
   On Tue, Nov 5, 2013 at 10:19 AM, David Nalley
   da...@gnsa.us
wrote:
  
   So perhaps a bit of history.
  
   nonoss/noredist is for targets that aren't built 'by
 default'
(e.g.
   you must explicitly turn them on). We do this because the
   ASF wants the default build to be truly unencumbered and
   where there are dependencies on non-open source, or
   non-Apache compatible code, we typically turn them off. In
   example: historically, Netscaler libraries were not open
   source, and we had a
  dependency
   on those libraries, so we placed the netscaler plugin into
   the nonoss. Since then the netscaler libraries have been
   open sourced, and we could move those out of noredist.
  
   So - is there third party code that you have as a build or
   runtime dependency? If so what is the license for that
   third party code? (My really fast perusal didn't catch
   anything that was immediately
   troubling)
  
   --David
  
   On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens
   wstev...@cloudops.com
   wrote:
Its dependence on a third party API and appliance,
similar to the
 srx
   and
netscaler. I am not convinced it should be in noredist,
but I was
   following
the same model as other similar plugins.  Feedback on
this would be helpful.
   
Ws
   
On Tuesday, November 5, 2013, David Nalley wrote:
   
On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
 wstev...@cloudops.com
   javascript:;
wrote:
 Sheng, I will rebuild the patch for the latest master.
 The
 latest
   master
 has depreciated the 'nonoss' flag in favour of
 'noredist'.
  I
 was
   building
 in nonoss previously. I am guessing I should use the
 noredist
 flag
   now

Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-07 Thread Will Stevens
Perfect.  Thank you for the details.


On Thu, Nov 7, 2013 at 1:59 PM, Sheng Yang sh...@yasker.org wrote:

 Oh, that means something wrong with the license header of the file(header
 missing in this case).

 http://creadur.apache.org/rat/

 --Sheng


 On Thu, Nov 7, 2013 at 10:50 AM, Will Stevens wstev...@cloudops.com
 wrote:

  Just so I know, can you explain what it means to 'Fail RAT'?  Thx...
 
 
  On Thu, Nov 7, 2013 at 1:46 PM, Sheng Yang sh...@yasker.org wrote:
 
   Fixed.
  
   --Sheng
  
  
   On Thu, Nov 7, 2013 at 10:23 AM, Animesh Chaturvedi 
   animesh.chaturv...@citrix.com wrote:
  
Fails RAT on
   
  
 
 plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientWrapper.java
   
   
 -Original Message-
 From: williamstev...@gmail.com [mailto:williamstev...@gmail.com]
 On
 Behalf Of Will Stevens
 Sent: Wednesday, November 06, 2013 10:15 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [Merge] Palo Alto Networks firewall integration to
  master

 Great!  Thank you Sheng...


 On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang sh...@yasker.org
 wrote:

  Looks good to me.
 
  Applied to MASTER branch. Thanks!
 
  --Sheng
 
 
  On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens 
  wstev...@cloudops.com
  wrote:
 
   @Sheng:  This should be ready to go now.  I built the patch
 from
  tonight's
   master and I included a more detailed commit message as you
 requested.
   Let
   me know if you have any questions/problems...
  
   @David:  As per this discussion (and a previous one [1]), I
 have
   moved
  this
   code from being built with the depreciated 'nonoss' flag to
 core
   since it does not depend on any 3rd party libraries at build or
 runtime.
  
   Cheers,
  
   Will
  
   [1]
  
  
 
   http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Einc
  ubator%2Ecloudstack-%2A+Palo+Alto
  
  
   On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens
   wstev...@cloudops.com
   wrote:
  
Thanks for that David.  You are absolutely correct, this
 plugin
has no dependencies on any 3rd party code at build or
 runtime.
Everything the plugin requires is built into the plugin.  I
 was
unclear if its
   dependance
on a 3rd party API and appliance to be functional was
 relevant.
   
I think you are right.  I think it should probably be in the
  core
  build.
 I will make that change when I merge in the latest master
 for
Sheng
  and
rebuild the patch.
   
Thanks,
   
Will
   
   
On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us
 
 wrote:
   
So perhaps a bit of history.
   
nonoss/noredist is for targets that aren't built 'by
 default'
 (e.g.
you must explicitly turn them on). We do this because the
 ASF
wants the default build to be truly unencumbered and where
  there
are dependencies on non-open source, or non-Apache
 compatible
code, we typically turn them off. In example: historically,
Netscaler libraries were not open source, and we had a
   dependency
on those libraries, so we placed the netscaler plugin into
 the
nonoss. Since then the netscaler libraries have been open
sourced, and we could move those out of noredist.
   
So - is there third party code that you have as a build or
runtime dependency? If so what is the license for that third
party code? (My really fast perusal didn't catch anything
 that
was immediately
troubling)
   
--David
   
On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens
wstev...@cloudops.com
wrote:
 Its dependence on a third party API and appliance, similar
  to
 the
  srx
and
 netscaler. I am not convinced it should be in noredist,
 but
  I
 was
following
 the same model as other similar plugins.  Feedback on this
 would be helpful.

 Ws

 On Tuesday, November 5, 2013, David Nalley wrote:

 On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
  wstev...@cloudops.com
javascript:;
 wrote:
  Sheng, I will rebuild the patch for the latest master.
   The
  latest
master
  has depreciated the 'nonoss' flag in favour of
  'noredist'.
   I
  was
building
  in nonoss previously. I am guessing I should use the
  noredist
  flag
now?
 

 Will - what is causing this to be noredist/nonoss? My
 quick
 perusal
   of
 your patch didn't surface anything that would push it
 into
 that category

Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-07 Thread Chip Childers
On Thu, Nov 07, 2013 at 06:59:25PM +, Animesh Chaturvedi wrote:
 mvn --projects='org.apache.cloudstack:cloudstack' 
 org.apache.rat:apache-rat-plugin:0.8:check

s/0.8/0.10 if you want the latest


Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-06 Thread Sheng Yang
Looks good to me.

Applied to MASTER branch. Thanks!

--Sheng


On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens wstev...@cloudops.com wrote:

 @Sheng:  This should be ready to go now.  I built the patch from tonight's
 master and I included a more detailed commit message as you requested.  Let
 me know if you have any questions/problems...

 @David:  As per this discussion (and a previous one [1]), I have moved this
 code from being built with the depreciated 'nonoss' flag to core since it
 does not depend on any 3rd party libraries at build or runtime.

 Cheers,

 Will

 [1]

 http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto


 On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens wstev...@cloudops.com
 wrote:

  Thanks for that David.  You are absolutely correct, this plugin has no
  dependencies on any 3rd party code at build or runtime.  Everything the
  plugin requires is built into the plugin.  I was unclear if its
 dependance
  on a 3rd party API and appliance to be functional was relevant.
 
  I think you are right.  I think it should probably be in the core build.
   I will make that change when I merge in the latest master for Sheng and
  rebuild the patch.
 
  Thanks,
 
  Will
 
 
  On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us wrote:
 
  So perhaps a bit of history.
 
  nonoss/noredist is for targets that aren't built 'by default' (e.g.
  you must explicitly turn them on). We do this because the ASF wants
  the default build to be truly unencumbered and where there are
  dependencies on non-open source, or non-Apache compatible code, we
  typically turn them off. In example: historically, Netscaler libraries
  were not open source, and we had a dependency on those libraries, so
  we placed the netscaler plugin into the nonoss. Since then the
  netscaler libraries have been open sourced, and we could move those
  out of noredist.
 
  So - is there third party code that you have as a build or runtime
  dependency? If so what is the license for that third party code? (My
  really fast perusal didn't catch anything that was immediately
  troubling)
 
  --David
 
  On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens wstev...@cloudops.com
  wrote:
   Its dependence on a third party API and appliance, similar to the srx
  and
   netscaler. I am not convinced it should be in noredist, but I was
  following
   the same model as other similar plugins.  Feedback on this would be
   helpful.
  
   Ws
  
   On Tuesday, November 5, 2013, David Nalley wrote:
  
   On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens wstev...@cloudops.com
  javascript:;
   wrote:
Sheng, I will rebuild the patch for the latest master.  The latest
  master
has depreciated the 'nonoss' flag in favour of 'noredist'. I was
  building
in nonoss previously. I am guessing I should use the noredist flag
  now?
   
  
   Will - what is causing this to be noredist/nonoss? My quick perusal
 of
   your patch didn't surface anything that would push it into that
   category.
  
   --David
  
 
 
 



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-06 Thread Will Stevens
Great!  Thank you Sheng...


On Wed, Nov 6, 2013 at 1:10 PM, Sheng Yang sh...@yasker.org wrote:

 Looks good to me.

 Applied to MASTER branch. Thanks!

 --Sheng


 On Tue, Nov 5, 2013 at 7:51 PM, Will Stevens wstev...@cloudops.com
 wrote:

  @Sheng:  This should be ready to go now.  I built the patch from
 tonight's
  master and I included a more detailed commit message as you requested.
  Let
  me know if you have any questions/problems...
 
  @David:  As per this discussion (and a previous one [1]), I have moved
 this
  code from being built with the depreciated 'nonoss' flag to core since it
  does not depend on any 3rd party libraries at build or runtime.
 
  Cheers,
 
  Will
 
  [1]
 
 
 http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
 
 
  On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens wstev...@cloudops.com
  wrote:
 
   Thanks for that David.  You are absolutely correct, this plugin has no
   dependencies on any 3rd party code at build or runtime.  Everything the
   plugin requires is built into the plugin.  I was unclear if its
  dependance
   on a 3rd party API and appliance to be functional was relevant.
  
   I think you are right.  I think it should probably be in the core
 build.
I will make that change when I merge in the latest master for Sheng
 and
   rebuild the patch.
  
   Thanks,
  
   Will
  
  
   On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us wrote:
  
   So perhaps a bit of history.
  
   nonoss/noredist is for targets that aren't built 'by default' (e.g.
   you must explicitly turn them on). We do this because the ASF wants
   the default build to be truly unencumbered and where there are
   dependencies on non-open source, or non-Apache compatible code, we
   typically turn them off. In example: historically, Netscaler libraries
   were not open source, and we had a dependency on those libraries, so
   we placed the netscaler plugin into the nonoss. Since then the
   netscaler libraries have been open sourced, and we could move those
   out of noredist.
  
   So - is there third party code that you have as a build or runtime
   dependency? If so what is the license for that third party code? (My
   really fast perusal didn't catch anything that was immediately
   troubling)
  
   --David
  
   On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens wstev...@cloudops.com
   wrote:
Its dependence on a third party API and appliance, similar to the
 srx
   and
netscaler. I am not convinced it should be in noredist, but I was
   following
the same model as other similar plugins.  Feedback on this would be
helpful.
   
Ws
   
On Tuesday, November 5, 2013, David Nalley wrote:
   
On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
 wstev...@cloudops.com
   javascript:;
wrote:
 Sheng, I will rebuild the patch for the latest master.  The
 latest
   master
 has depreciated the 'nonoss' flag in favour of 'noredist'. I was
   building
 in nonoss previously. I am guessing I should use the noredist
 flag
   now?

   
Will - what is causing this to be noredist/nonoss? My quick perusal
  of
your patch didn't surface anything that would push it into that
category.
   
--David
   
  
  
  
 



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-05 Thread Will Stevens
Its dependence on a third party API and appliance, similar to the srx and
netscaler. I am not convinced it should be in noredist, but I was following
the same model as other similar plugins.  Feedback on this would be
helpful.

Ws

On Tuesday, November 5, 2013, David Nalley wrote:

 On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
 wstev...@cloudops.comjavascript:;
 wrote:
  Sheng, I will rebuild the patch for the latest master.  The latest master
  has depreciated the 'nonoss' flag in favour of 'noredist'. I was building
  in nonoss previously. I am guessing I should use the noredist flag now?
 

 Will - what is causing this to be noredist/nonoss? My quick perusal of
 your patch didn't surface anything that would push it into that
 category.

 --David



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-05 Thread David Nalley
So perhaps a bit of history.

nonoss/noredist is for targets that aren't built 'by default' (e.g.
you must explicitly turn them on). We do this because the ASF wants
the default build to be truly unencumbered and where there are
dependencies on non-open source, or non-Apache compatible code, we
typically turn them off. In example: historically, Netscaler libraries
were not open source, and we had a dependency on those libraries, so
we placed the netscaler plugin into the nonoss. Since then the
netscaler libraries have been open sourced, and we could move those
out of noredist.

So - is there third party code that you have as a build or runtime
dependency? If so what is the license for that third party code? (My
really fast perusal didn't catch anything that was immediately
troubling)

--David

On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens wstev...@cloudops.com wrote:
 Its dependence on a third party API and appliance, similar to the srx and
 netscaler. I am not convinced it should be in noredist, but I was following
 the same model as other similar plugins.  Feedback on this would be
 helpful.

 Ws

 On Tuesday, November 5, 2013, David Nalley wrote:

 On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens 
 wstev...@cloudops.comjavascript:;
 wrote:
  Sheng, I will rebuild the patch for the latest master.  The latest master
  has depreciated the 'nonoss' flag in favour of 'noredist'. I was building
  in nonoss previously. I am guessing I should use the noredist flag now?
 

 Will - what is causing this to be noredist/nonoss? My quick perusal of
 your patch didn't surface anything that would push it into that
 category.

 --David



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-05 Thread Will Stevens
Thanks for that David.  You are absolutely correct, this plugin has no
dependencies on any 3rd party code at build or runtime.  Everything the
plugin requires is built into the plugin.  I was unclear if its dependance
on a 3rd party API and appliance to be functional was relevant.

I think you are right.  I think it should probably be in the core build.  I
will make that change when I merge in the latest master for Sheng and
rebuild the patch.

Thanks,

Will


On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us wrote:

 So perhaps a bit of history.

 nonoss/noredist is for targets that aren't built 'by default' (e.g.
 you must explicitly turn them on). We do this because the ASF wants
 the default build to be truly unencumbered and where there are
 dependencies on non-open source, or non-Apache compatible code, we
 typically turn them off. In example: historically, Netscaler libraries
 were not open source, and we had a dependency on those libraries, so
 we placed the netscaler plugin into the nonoss. Since then the
 netscaler libraries have been open sourced, and we could move those
 out of noredist.

 So - is there third party code that you have as a build or runtime
 dependency? If so what is the license for that third party code? (My
 really fast perusal didn't catch anything that was immediately
 troubling)

 --David

 On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens wstev...@cloudops.com
 wrote:
  Its dependence on a third party API and appliance, similar to the srx and
  netscaler. I am not convinced it should be in noredist, but I was
 following
  the same model as other similar plugins.  Feedback on this would be
  helpful.
 
  Ws
 
  On Tuesday, November 5, 2013, David Nalley wrote:
 
  On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens wstev...@cloudops.com
 javascript:;
  wrote:
   Sheng, I will rebuild the patch for the latest master.  The latest
 master
   has depreciated the 'nonoss' flag in favour of 'noredist'. I was
 building
   in nonoss previously. I am guessing I should use the noredist flag
 now?
  
 
  Will - what is causing this to be noredist/nonoss? My quick perusal of
  your patch didn't surface anything that would push it into that
  category.
 
  --David
 



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-05 Thread Will Stevens
@Sheng:  This should be ready to go now.  I built the patch from tonight's
master and I included a more detailed commit message as you requested.  Let
me know if you have any questions/problems...

@David:  As per this discussion (and a previous one [1]), I have moved this
code from being built with the depreciated 'nonoss' flag to core since it
does not depend on any 3rd party libraries at build or runtime.

Cheers,

Will

[1]
http://markmail.org/message/fxphjkba7bonlesd?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto


On Tue, Nov 5, 2013 at 11:42 AM, Will Stevens wstev...@cloudops.com wrote:

 Thanks for that David.  You are absolutely correct, this plugin has no
 dependencies on any 3rd party code at build or runtime.  Everything the
 plugin requires is built into the plugin.  I was unclear if its dependance
 on a 3rd party API and appliance to be functional was relevant.

 I think you are right.  I think it should probably be in the core build.
  I will make that change when I merge in the latest master for Sheng and
 rebuild the patch.

 Thanks,

 Will


 On Tue, Nov 5, 2013 at 10:19 AM, David Nalley da...@gnsa.us wrote:

 So perhaps a bit of history.

 nonoss/noredist is for targets that aren't built 'by default' (e.g.
 you must explicitly turn them on). We do this because the ASF wants
 the default build to be truly unencumbered and where there are
 dependencies on non-open source, or non-Apache compatible code, we
 typically turn them off. In example: historically, Netscaler libraries
 were not open source, and we had a dependency on those libraries, so
 we placed the netscaler plugin into the nonoss. Since then the
 netscaler libraries have been open sourced, and we could move those
 out of noredist.

 So - is there third party code that you have as a build or runtime
 dependency? If so what is the license for that third party code? (My
 really fast perusal didn't catch anything that was immediately
 troubling)

 --David

 On Tue, Nov 5, 2013 at 7:08 AM, Will Stevens wstev...@cloudops.com
 wrote:
  Its dependence on a third party API and appliance, similar to the srx
 and
  netscaler. I am not convinced it should be in noredist, but I was
 following
  the same model as other similar plugins.  Feedback on this would be
  helpful.
 
  Ws
 
  On Tuesday, November 5, 2013, David Nalley wrote:
 
  On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens wstev...@cloudops.com
 javascript:;
  wrote:
   Sheng, I will rebuild the patch for the latest master.  The latest
 master
   has depreciated the 'nonoss' flag in favour of 'noredist'. I was
 building
   in nonoss previously. I am guessing I should use the noredist flag
 now?
  
 
  Will - what is causing this to be noredist/nonoss? My quick perusal of
  your patch didn't surface anything that would push it into that
  category.
 
  --David
 





Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-04 Thread Chip Childers
On Mon, Nov 04, 2013 at 10:49:29AM -0500, Will Stevens wrote:
 Anything I can do to help get this patch into 4.3.0?
 
 Thanks,
 
 Will

If it's in master, it'll be in 4.3...  so help by testing during the 4.3
test cycle!

-chip


Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-04 Thread Will Stevens
Anything I can do to help get this patch into 4.3.0?

Thanks,

Will


On Fri, Nov 1, 2013 at 2:47 PM, Sheng Yang sh...@yasker.org wrote:

 Nice work Will!

 I've checked the code, it included the UI part and unit test as well.
 Really impressed!

 Just one comment: you can git-format-patch to generate the patch. It would
 includes author and description information automatically, which is easier
 for applying.

 +1!

 --Sheng



 On Thu, Oct 31, 2013 at 1:50 PM, Will Stevens wstev...@cloudops.com
 wrote:

  Hi,
 
  I would like to merge support for Palo Alto Network's firewall appliances
  to the master branch.  Development for this has been done by Will Stevens
  at CloudOps on branch [1].
 
  There was an introduction [2], a proposal [3], and a discussion [4] on
 the
  mailing list regarding this feature.
 
  Checklist:
  Jira ticket for the feature is here [5].
  The FS can be found at [6].
  Unit tests for the feature are available at [7] and [8].  I have
 developed
  the unit tests with a flag to output additional detail in the console
 [9].
   Here is the result of the tests without detail [10] and here is the
 result
  of the tests with detail [11].
 
  This plugin communicates to the Palo Alto Networks firewall appliances
  through an API documented at [12] with a training manual [13].
  This plugin depends on a modification to core to remove a limitation
 which
  was discussed here [14], with this jira issue [15] and has been approved
  here [16].
  This plugin is being reviewed at [17] according to this patch [18].
 
  There are no 3rd party libraries needed for this plugin, however it does
  depend on a 3rd party API [12][13] to orchestrate the configuration on
 the
  appliance.  The plugin is currently being built via the 'nonoss' flag.
  It
  should be moved into either the 'noredist' or core because it appears
 that
  'nonoss' will be going away [19] and 'noredist' has been merged [20].  I
  would appreciate input on which build this should be put into given its
  interaction with an 3rd party appliance.
 
  Here are the slides for a presentation [21] given about this integration
 at
  the CloudStack Collaboration Conference in Santa Clara, CA.
 
  [1] https://github.com/cloudops/cs_palo_alto/tree/palo_alto
  [2]
 
 
 http://markmail.org/message/hukydzwkec3dwuxq?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
  [3]
 
 
 http://markmail.org/message/odbg2icft7esj3ut?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
  [4]
 
 
 http://markmail.org/message/n5276i4hfh7ek57o?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
  [5] https://issues.apache.org/jira/browse/CLOUDSTACK-1275
  [6]
 
 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
  [7]
 
 
 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java
  [8]
 
 
 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/MockablePaloAltoResource.java
  [9]
 
 
 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java#L156
  [10]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_without_logging.txt?version=1modificationDate=1383248404474
  [11]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_with_logging.txt?version=1modificationDate=1383248432061
  [12]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/XML-API-5-1.0-RevA.pdf?version=1modificationDate=1366305634000
  [13]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/XML_API_Training.pdf?version=1modificationDate=1366305635000
  [14]
 
 
 http://markmail.org/message/374hyn7ko6zrb2cf?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+supported+source+nat+types
  [15] https://issues.apache.org/jira/browse/CLOUDSTACK-4991
  [16] https://reviews.apache.org/r/15047/
  [17] https://reviews.apache.org/r/15050/
  [18] https://reviews.apache.org/r/15050/diff/
  [19]
 
 
 http://markmail.org/message/37qcg4lgudmf57ws?q=DISCUSS%5D+rename+nonoss+to+noredist
  [20]
 
 
 http://markmail.org/message/zqkiuod5qabcyra6?q=%5BMERGE%5D+changing+nonoss+to+noredist
  [21]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/CS_PA_Integration.pptx?version=1modificationDate=1383250830719
 
  Cheers,
 
  Will
 



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-04 Thread Will Stevens
Well its not in master yet.  That is the intent of this thread...

I can definitely do some testing for the 4.3 test cycle.

Will


On Mon, Nov 4, 2013 at 10:56 AM, Chip Childers chipchild...@apache.orgwrote:

 On Mon, Nov 04, 2013 at 10:49:29AM -0500, Will Stevens wrote:
  Anything I can do to help get this patch into 4.3.0?
 
  Thanks,
 
  Will

 If it's in master, it'll be in 4.3...  so help by testing during the 4.3
 test cycle!

 -chip



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-04 Thread Chip Childers
On Mon, Nov 04, 2013 at 10:59:30AM -0500, Will Stevens wrote:
 Well its not in master yet.  That is the intent of this thread...
 
 I can definitely do some testing for the 4.3 test cycle.
 
 Will

Shoot, I misread Sheng's email.  Sorry about that.  I thought he said
that he Checked *in* the code, not Checked out.

Duh... my bad.

Sheng, as the reviewer, want to handle the commit?


Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-04 Thread Sheng Yang
Sure, I would be glad to commit it for 4.3 release.

--Sheng


On Mon, Nov 4, 2013 at 8:19 AM, Chip Childers chipchild...@apache.orgwrote:

 On Mon, Nov 04, 2013 at 10:59:30AM -0500, Will Stevens wrote:
  Well its not in master yet.  That is the intent of this thread...
 
  I can definitely do some testing for the 4.3 test cycle.
 
  Will

 Shoot, I misread Sheng's email.  Sorry about that.  I thought he said
 that he Checked *in* the code, not Checked out.

 Duh... my bad.

 Sheng, as the reviewer, want to handle the commit?



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-04 Thread Will Stevens
Sheng, I will rebuild the patch for the latest master.  The latest master
has depreciated the 'nonoss' flag in favour of 'noredist'. I was building
in nonoss previously. I am guessing I should use the noredist flag now?

Cheers,

Will

On Monday, November 4, 2013, Sheng Yang wrote:

 Sure, I would be glad to commit it for 4.3 release.

 --Sheng


 On Mon, Nov 4, 2013 at 8:19 AM, Chip Childers 
 chipchild...@apache.orgjavascript:;
 wrote:

  On Mon, Nov 04, 2013 at 10:59:30AM -0500, Will Stevens wrote:
   Well its not in master yet.  That is the intent of this thread...
  
   I can definitely do some testing for the 4.3 test cycle.
  
   Will
 
  Shoot, I misread Sheng's email.  Sorry about that.  I thought he said
  that he Checked *in* the code, not Checked out.
 
  Duh... my bad.
 
  Sheng, as the reviewer, want to handle the commit?
 



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-04 Thread David Nalley
On Mon, Nov 4, 2013 at 7:32 PM, Will Stevens wstev...@cloudops.com wrote:
 Sheng, I will rebuild the patch for the latest master.  The latest master
 has depreciated the 'nonoss' flag in favour of 'noredist'. I was building
 in nonoss previously. I am guessing I should use the noredist flag now?


Will - what is causing this to be noredist/nonoss? My quick perusal of
your patch didn't surface anything that would push it into that
category.

--David


Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-01 Thread Sheng Yang
Nice work Will!

I've checked the code, it included the UI part and unit test as well.
Really impressed!

Just one comment: you can git-format-patch to generate the patch. It would
includes author and description information automatically, which is easier
for applying.

+1!

--Sheng



On Thu, Oct 31, 2013 at 1:50 PM, Will Stevens wstev...@cloudops.com wrote:

 Hi,

 I would like to merge support for Palo Alto Network's firewall appliances
 to the master branch.  Development for this has been done by Will Stevens
 at CloudOps on branch [1].

 There was an introduction [2], a proposal [3], and a discussion [4] on the
 mailing list regarding this feature.

 Checklist:
 Jira ticket for the feature is here [5].
 The FS can be found at [6].
 Unit tests for the feature are available at [7] and [8].  I have developed
 the unit tests with a flag to output additional detail in the console [9].
  Here is the result of the tests without detail [10] and here is the result
 of the tests with detail [11].

 This plugin communicates to the Palo Alto Networks firewall appliances
 through an API documented at [12] with a training manual [13].
 This plugin depends on a modification to core to remove a limitation which
 was discussed here [14], with this jira issue [15] and has been approved
 here [16].
 This plugin is being reviewed at [17] according to this patch [18].

 There are no 3rd party libraries needed for this plugin, however it does
 depend on a 3rd party API [12][13] to orchestrate the configuration on the
 appliance.  The plugin is currently being built via the 'nonoss' flag.  It
 should be moved into either the 'noredist' or core because it appears that
 'nonoss' will be going away [19] and 'noredist' has been merged [20].  I
 would appreciate input on which build this should be put into given its
 interaction with an 3rd party appliance.

 Here are the slides for a presentation [21] given about this integration at
 the CloudStack Collaboration Conference in Santa Clara, CA.

 [1] https://github.com/cloudops/cs_palo_alto/tree/palo_alto
 [2]

 http://markmail.org/message/hukydzwkec3dwuxq?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
 [3]

 http://markmail.org/message/odbg2icft7esj3ut?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
 [4]

 http://markmail.org/message/n5276i4hfh7ek57o?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
 [5] https://issues.apache.org/jira/browse/CLOUDSTACK-1275
 [6]

 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
 [7]

 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java
 [8]

 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/MockablePaloAltoResource.java
 [9]

 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java#L156
 [10]

 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_without_logging.txt?version=1modificationDate=1383248404474
 [11]

 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_with_logging.txt?version=1modificationDate=1383248432061
 [12]

 https://cwiki.apache.org/confluence/download/attachments/30753712/XML-API-5-1.0-RevA.pdf?version=1modificationDate=1366305634000
 [13]

 https://cwiki.apache.org/confluence/download/attachments/30753712/XML_API_Training.pdf?version=1modificationDate=1366305635000
 [14]

 http://markmail.org/message/374hyn7ko6zrb2cf?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+supported+source+nat+types
 [15] https://issues.apache.org/jira/browse/CLOUDSTACK-4991
 [16] https://reviews.apache.org/r/15047/
 [17] https://reviews.apache.org/r/15050/
 [18] https://reviews.apache.org/r/15050/diff/
 [19]

 http://markmail.org/message/37qcg4lgudmf57ws?q=DISCUSS%5D+rename+nonoss+to+noredist
 [20]

 http://markmail.org/message/zqkiuod5qabcyra6?q=%5BMERGE%5D+changing+nonoss+to+noredist
 [21]

 https://cwiki.apache.org/confluence/download/attachments/30753712/CS_PA_Integration.pptx?version=1modificationDate=1383250830719

 Cheers,

 Will



Re: [Merge] Palo Alto Networks firewall integration to master

2013-11-01 Thread Will Stevens
Great, thank you Sheng...

I have updated the diff for the patch review with a new version which was
created using the 'git format-patch' format.

A note that may help others.  I found this very helpful when squashing my
branch of changes to a patch for master:
http://stackoverflow.com/questions/616556/how-do-you-squash-commits-into-one-patch-with-git-format-patch?answertab=votes#tab-top


On Fri, Nov 1, 2013 at 2:47 PM, Sheng Yang sh...@yasker.org wrote:

 Nice work Will!

 I've checked the code, it included the UI part and unit test as well.
 Really impressed!

 Just one comment: you can git-format-patch to generate the patch. It would
 includes author and description information automatically, which is easier
 for applying.

 +1!

 --Sheng



 On Thu, Oct 31, 2013 at 1:50 PM, Will Stevens wstev...@cloudops.com
 wrote:

  Hi,
 
  I would like to merge support for Palo Alto Network's firewall appliances
  to the master branch.  Development for this has been done by Will Stevens
  at CloudOps on branch [1].
 
  There was an introduction [2], a proposal [3], and a discussion [4] on
 the
  mailing list regarding this feature.
 
  Checklist:
  Jira ticket for the feature is here [5].
  The FS can be found at [6].
  Unit tests for the feature are available at [7] and [8].  I have
 developed
  the unit tests with a flag to output additional detail in the console
 [9].
   Here is the result of the tests without detail [10] and here is the
 result
  of the tests with detail [11].
 
  This plugin communicates to the Palo Alto Networks firewall appliances
  through an API documented at [12] with a training manual [13].
  This plugin depends on a modification to core to remove a limitation
 which
  was discussed here [14], with this jira issue [15] and has been approved
  here [16].
  This plugin is being reviewed at [17] according to this patch [18].
 
  There are no 3rd party libraries needed for this plugin, however it does
  depend on a 3rd party API [12][13] to orchestrate the configuration on
 the
  appliance.  The plugin is currently being built via the 'nonoss' flag.
  It
  should be moved into either the 'noredist' or core because it appears
 that
  'nonoss' will be going away [19] and 'noredist' has been merged [20].  I
  would appreciate input on which build this should be put into given its
  interaction with an 3rd party appliance.
 
  Here are the slides for a presentation [21] given about this integration
 at
  the CloudStack Collaboration Conference in Santa Clara, CA.
 
  [1] https://github.com/cloudops/cs_palo_alto/tree/palo_alto
  [2]
 
 
 http://markmail.org/message/hukydzwkec3dwuxq?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
  [3]
 
 
 http://markmail.org/message/odbg2icft7esj3ut?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
  [4]
 
 
 http://markmail.org/message/n5276i4hfh7ek57o?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Palo+Alto
  [5] https://issues.apache.org/jira/browse/CLOUDSTACK-1275
  [6]
 
 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
  [7]
 
 
 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java
  [8]
 
 
 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/MockablePaloAltoResource.java
  [9]
 
 
 https://github.com/cloudops/cs_palo_alto/blob/palo_alto/plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java#L156
  [10]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_without_logging.txt?version=1modificationDate=1383248404474
  [11]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/palo_alto_tests_with_logging.txt?version=1modificationDate=1383248432061
  [12]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/XML-API-5-1.0-RevA.pdf?version=1modificationDate=1366305634000
  [13]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/XML_API_Training.pdf?version=1modificationDate=1366305635000
  [14]
 
 
 http://markmail.org/message/374hyn7ko6zrb2cf?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+supported+source+nat+types
  [15] https://issues.apache.org/jira/browse/CLOUDSTACK-4991
  [16] https://reviews.apache.org/r/15047/
  [17] https://reviews.apache.org/r/15050/
  [18] https://reviews.apache.org/r/15050/diff/
  [19]
 
 
 http://markmail.org/message/37qcg4lgudmf57ws?q=DISCUSS%5D+rename+nonoss+to+noredist
  [20]
 
 
 http://markmail.org/message/zqkiuod5qabcyra6?q=%5BMERGE%5D+changing+nonoss+to+noredist
  [21]
 
 
 https://cwiki.apache.org/confluence/download/attachments/30753712/CS_PA_Integration.pptx?version=1modificationDate=1383250830719
 
  Cheers,
 
  Will