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