incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: [PROPOSE] Palo Alto Firewall Integration
Date Thu, 14 Feb 2013 18:13:52 GMT
Thanks for the information as well as the jira permissions.  I have
assigned the issue to myself.

I will keep it in 'nonoss' for now and as I get near the end of the project
I can make a more educated decision on that point.  The change is pretty
simple and it won't impact the implementation of the code, so its a
non-blocking issue for now.

Thanks again...


On Thu, Feb 14, 2013 at 12:54 PM, Chip Childers
<chip.childers@sungard.com>wrote:

> On Thu, Feb 14, 2013 at 12:24:13PM -0500, Will Stevens wrote:
> >    - I am currently compiling my code using the 'nonoss' flag similar to
> >    JuniperSRX, Netscaler, etc...  I will not be referencing any code
> external
> >    to CloudStack, but I will be integrating with the Palo Alto API.  I
> need to
> >    confirm that the Palo Alto API documentation can be made publicly
> >    accessible.  What is the standard practice regarding the nonoss flag
> and
> >    when it should be used?
>
> The non-oss flag is basically so that our default build does not pull in
> non ASLv2 compatible dependencies (as defined by the ASF legal folks).
> In the scenario that you describe, you are creating CloudStack code that
> will call a remote web service API, which means you are not adding a new
> dependency to the project.  Based on this, there's no reason that you
> would need your code to be in the non-default build (but we'll adjust as
> needed as you get further along).
>
> One point to note - Inclusion of the WSDL in our code may be
> questionable.  Inclusion of proxy class files generated from that WSDL
> should not be a problem.
>
> > Also, I do not have permission to assign the New Feature issue I created
> in
> > Jira to myself, so if someone could do that for me that would be great
> > (link is in the spec).
>
> You have permission now.  Give it a shot!
>
> -chip
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message