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 >>>>>> >>>>> >>>> >>> >>