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