I created https://issues.apache.org/jira/browse/ARIA-388 to capture
this.
—Tom
> On Oct 10, 2017, at 4:09 PM, DeWayne Filppi <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> 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 <[email protected]> wrote:
>>>
>>>> Any help in debugging would be appreciated!
>>>>
>>>> On Tue, Oct 10, 2017 at 2:02 PM, DeWayne Filppi <[email protected]>
>>>> 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 <
>> [email protected]>
>>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>>
