cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manan Shah <>
Subject Re: [PROPOSE] Palo Alto Firewall Integration
Date Wed, 27 Feb 2013 00:05:11 GMT
Hi Will,

It is nice to see that you are adding integration with Palo Alto Firewall.
I have read the functional spec and I have a few additional questions.

1. Would this module work with all Palo Alto Firewalls or any specific
firewall models only?
2. Are you using all Publicly available APIs?
3. You mentioned that the Virtual Firewall is out-of-scope. Is that
because it uses a different set of APIs?
4. What use cases you plan to enable?
5. Are you going to enable it as a per-Tenant/per-Network instance?
Currently, there are some restrictions with the Juniper SRX support in
that you can't have multiple SRX supported per Zone and there is no way to
specify if you want to have a shared FW or a dedicated FW. It would be
quite useful if you can provide the functionality to support multiple FW /
Zone and identify them as dedicate or shared. Similar functionality exists
for Load balancers.
5. I know Virtual Firewalls are out of scope but if and when the support
is added, it would be good to add support for Life Cycle Management of
Palo Alto Firewalls?

Sorry in advance for so many questions but I wanted to better understand
the support you are providing.

Manan Shah

On 2/14/13 10:13 AM, "Will Stevens" <> wrote:

>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
>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
>> On Thu, Feb 14, 2013 at 12:24:13PM -0500, Will Stevens wrote:
>> >    - I am currently compiling my code using the 'nonoss' flag similar
>> >    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
>> 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
>> 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

View raw message