Hi,

The openstack operations are defined in openstack.yaml.  And yes, you'll
have to use the Cloudify cloud init plugin.  Note that youll have to create
a Tosca version of the types.yaml.

DeWayne



On Oct 11, 2017 4:22 PM, "Steve Baillargeon" <steve.baillarg...@ericsson.com>
wrote:

Hi DeWayne
Thank you for the great example.

Two follow-up questions:

1) I don't see the Standard interface definitions for the Openstack related
nodes in the main service template (except for private_network_subnet). Did
I miss something?

2) Say I want to use cloud-init to inject data (say one remote IP address
and a trusted CA certificate) from a config drive when the VNF is initially
deployed. Should I use/import the Cloudify cloud-init plugin instead?
https://github.com/cloudify-incubator/cloudify-utilities-
plugin/tree/master/cloudify_cloudinit

Regards
Steve B

-----Original Message-----
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
Sent: Wednesday, October 11, 2017 10:08 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Fortigate VNF template

Perfect!

Thx man.

—Tom


> On Oct 11, 2017, at 9:30 AM, DeWayne Filppi <dewa...@cloudify.co> wrote:
>
> I already provided more detail.  I'll see if I can boil it down into a
> focused example.
>
> On Tue, Oct 10, 2017 at 5:02 PM, Tal Liron <t...@cloudify.co> wrote:
>
>> Thanks, Tom. I'm pretty sure there already is just a JIRA... anyway,
>> I edited yours just to remove the other things, because DeWayne is
>> reporting a different issue here.
>>
>> DeWayne, could you you pretty please provide us with something more
>> than "blows a gasket"? What happens exactly and when, and could you
>> please try to isolate it to a minimal case?
>>
>> On Tue, Oct 10, 2017 at 3:24 PM, Thomas Nadeau
>> <tnadeaua...@gmail.com>
>> wrote:
>>
>>>
>>>        I created https://issues.apache.org/jira/browse/ARIA-388 to
>>> capture this.
>>>
>>>        —Tom
>>>
>>>
>>>> On Oct 10, 2017, at 4:09 PM, DeWayne Filppi <dewa...@cloudify.co>
>> wrote:
>>>>
>>>> Ok.  The interesting thing is that not only does it allow you to
>>>> have ad-hoc inputs, it also blows a gasket when you try to define them.
>>>>
>>>> On Tue, Oct 10, 2017 at 3:02 PM, Tal Liron <t...@cloudify.co> wrote:
>>>>
>>>>> ARIA right now lets you throw in ad hoc inputs, but I consider
>>>>> this to
>>> be a
>>>>> bug. So yes, I would say you absolutely need to declare your inputs.
>>>>>
>>>>> On Tue, Oct 10, 2017 at 2:46 PM, DeWayne Filppi
>>>>> <dewa...@cloudify.co>
>>>>> wrote:
>>>>>
>>>>>> So you'd agree that it should have required an explicit
>>>>>> definition of
>>> the
>>>>>> inputs?
>>>>>>
>>>>>> On Tue, Oct 10, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:
>>>>>>
>>>>>>> Any help in debugging would be appreciated!
>>>>>>>
>>>>>>> On Tue, Oct 10, 2017 at 2:02 PM, DeWayne Filppi <
>> dewa...@cloudify.co>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> For reasons that somewhat mystify me, the template is
>>>>>>>> installing
>> with
>>>>>> no
>>>>>>>> errors now.  I fixed it by removing the inputs definition I had
>>>>>>>> in
>>>>> the
>>>>>>>> terminal.yaml file, which is counter-intuitive.  I used to
>>>>>>>> have, in
>>>>> the
>>>>>>>> node type definition:
>>>>>>>>
>>>>>>>>   interfaces:
>>>>>>>>     Standard:
>>>>>>>>       create:
>>>>>>>>         implementation: cloudify-utilities-plugin >
>>>>>>>> cloudify_terminal.tasks.run
>>>>>>>>         inputs:
>>>>>>>>           calls:
>>>>>>>>             type: list
>>>>>>>>             entry_schema: call_type
>>>>>>>>
>>>>>>>> I defined the inputs because I thought I had to.  This was the
>> source
>>>>>> of
>>>>>>>> the error I mentioned in another thread (regarding yaml-1.1).
>>>>>>>> In
>> any
>>>>>>> case,
>>>>>>>> by commenting it out, I got no validation errors, and the
>>>>>>>> terminal
>>>>>> calls
>>>>>>>> are made as expected.  In the node template, I still pass inputs:
>>>>>>>>
>>>>>>>>     interfaces:
>>>>>>>>       Standard:
>>>>>>>>         create:
>>>>>>>>           inputs:
>>>>>>>>             calls:
>>>>>>>>               - action: exit
>>>>>>>>
>>>>>>>> This doesn't seem as though it should be possible.  In any
>>>>>>>> case,
>> the
>>>>>>> latest
>>>>>>>> has been pushed to the repo:
>>>>>>>> https://github.com/dfilppi/fortigate-tosca-example
>>>>>>>>
>>>>>>>> DeWayne
>>>>>>>>
>>>>>>>> On Tue, Oct 10, 2017 at 10:37 AM, DeWayne Filppi <
>>>>> dewa...@cloudify.co>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> For those interested, I'm in the process of implementing a
>>>>>>>>> TOSCA
>>>>>>> template
>>>>>>>>> for the initial deployment and configuration of a Fortigate
>>>>>>>>> VNF in Openstack.  It uses a couple of borrowed Cloudify
>>>>>>>>> plugins: one for Openstack itself
>>>>>>>>> (https://github.com/cloudify-
>>>>>>> cosmo/cloudify-openstack-
>>>>>>>>> plugin), and one for the terminal plugin (part of the Cloudify
>>>>>>> incubator
>>>>>>>>> "utilities" project (https://github.com/cloudify-
>>>>>>>>> incubator/cloudify-utilities-plugin).
>>>>>>>>>
>>>>>>>>> The basic idea is that a network and router is created with
>>>>>>>>> public
>>>>>>>> access,
>>>>>>>>> and a private network with no direct public access.  In
>>>>>>>>> between is
>>>>>> the
>>>>>>>>> Fortigate firewall VNF that controls access to instances
>>>>>>>>> running
>> on
>>>>>> the
>>>>>>>>> private network.  The initial template just sets up the VNF
>>>>>>>>> and
>>>>>>> networks.
>>>>>>>>> The next template (TBD) will deploy a service on the private
>>>>> network
>>>>>>> and
>>>>>>>>> reconfigure the firewall to allow access via port forwarding.
>>>>> This
>>>>>> is
>>>>>>>>> very much a work in progress (the VNF configuration isn't
>>>>>>>>> quite
>>>>>> working
>>>>>>>>> yet):
>>>>>>>>>
>>>>>>>>> https://github.com/dfilppi/fortigate-tosca-example
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>

Reply via email to