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 <[email protected]> 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 <[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 > >>>>>> > >>>>> > >>>> > >>> > >> > >
