Feel free to change the wiki, Ran, to whatever name you find appropriate. I think what Avia discovered is not new to us and actually doesn't solve the problem, unfortunately. Let me go over what is clearly allowed and not allowed in TOSCA, confusing because there are a few levels of inheritance here.
1. Interface types. Obviously, you are allowed to inherit an interface type and add or override inputs. (ARIA insists that overridden input types be derived from what it is they are overriding, too, to keep the OO contract intact.) 2. Node types. In the "interfaces" section you can define several interfaces of various types. Here, again, TOSCA lets you add/override inputs. Though note here that the line of inheritance is quite complex: you can override inputs from the interface type, but *also* from the parent node type. (ARIA here has to do some work to make sure that you are doing it all OK and not breaking the OO contract, it's a rather complex part of the parser code.) I think the above is what Avia discovered. However, the third level is locked to us: 3. Node templates. Unfortunately, here we can not add inputs ad hoc. The "interfaces" section here is not the same DSL format as those above: it is operation *assignments* rather than operation *definitions*. When you assign input values here, they are validated against the defined types. It would make no sense in TOSCA to just assign values without a type. So, because we can't add inputs at level #3, we still have a problem: we would have to derive new node types for every type of execution. SSH would require its own node types, Juju would require its own node types, Puppet would require its own node types, etc. And that's for *all* your node types. This seems extremely un-scalable. But also, as I try to explain in the wiki page, I insist that these kinds of configuration parameters are essentially not the same as operation inputs. They are not meant to be used by the operation itself (script, charm, recipe, etc.), rather by the mechanism that executes the operation (SSH, Juju, Puppet, etc.). Especially I point out the security hole: you don't want an SSH password exposed and sent over the wire to the script itself. It is simply not an input. By the way, it seems that there's some acknowledgement by other folk in OASIS about this gap in TOSCA, and there's an interest to use artifact types in TOSCA 1.2 as a way to solve this problem. I don't think it's a bit awkward, but at least there will be a standard solution. On Sun, Sep 10, 2017 at 2:13 AM, Ran Ziv <[email protected]> wrote: > Avia's mentioned at one point that we might have misunderstood the spec at > this section, and that in fact it can be possible to pass arbitrary inputs > into operations regardless of the interface definition - which would mean > this notion of "configuration" might be unnecessary. > > Also, note that the doc page is talking about "executors", which is > confusing as that's a different concept in ARIA (see the base executor > class); Supposedly up until now we've simply called these "operation > plugins". > > > On Sat, Sep 9, 2017 at 1:43 AM, Tal Liron <[email protected]> wrote: > > > Yes: > > https://cwiki.apache.org/confluence/display/ARIATOSCA/ > > Execution+Configuration > > > > On Fri, Sep 8, 2017 at 4:45 PM, DeWayne Filppi <[email protected]> > > wrote: > > > > > I see in the examples a list of dependencies for scripts in operations, > > for > > > example: > > > > > > implementation: > > > primary: scripts/configure.sh > > > dependencies: > > > - "ssh.user > { get_input: ssh_username }" > > > - "ssh.key_filename > { get_input: private_key_path }" > > > - "ssh.address > { get_attribute: [ virtual_ip, > > > floating_ip_address ] }" > > > > > > The spec seems to indicate that the dependency list is for resources > that > > > need to be made available so the main script can be run. Clearly that > > > isn't the case in the example. Is this '>' syntax documented anywhere? > > > > > >
