Hi DeWayne Thank you for the great example. Two follow-up questions:
1) I don't see the Standard interface definitions for the Openstack related nodes in the main service template (except for private_network_subnet). Did I miss something? 2) Say I want to use cloud-init to inject data (say one remote IP address and a trusted CA certificate) from a config drive when the VNF is initially deployed. Should I use/import the Cloudify cloud-init plugin instead? https://github.com/cloudify-incubator/cloudify-utilities-plugin/tree/master/cloudify_cloudinit Regards Steve B -----Original Message----- From: Thomas Nadeau [mailto:[email protected]] Sent: Wednesday, October 11, 2017 10:08 AM To: [email protected] Subject: Re: Fortigate VNF template Perfect! Thx man. —Tom > On Oct 11, 2017, at 9:30 AM, DeWayne Filppi <[email protected]> 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 <[email protected]> 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 >> <[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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>
