We briefly discussed some controversial aspects of operations and inputs in the last ad-hoc meeting.
At stake is that it's possible to assign un-defined inputs to an operation at the node template: un-defined at both the interface type and at the interface definition within the node type. These additional inputs are ad hoc. They have no defined data type (although it might be inferrable in some cases).
This feature feels very unlike the rest of TOSCA. Not only because this is untyped data, but relatedly there is no type/contract-assured guarantee that the executor of the operation (an artifact? an API subsystem?) would be able to consume these inputs, let alone do anything useful with them. The interface type should be a contract, but here we allow designers to break it. Sure, some dynamic languages like Python can accept "kwargs" to functions and just ignore them. But many languages have strict function signatures, and most CLI tools would error out if they get an unknown or malformed argument. TOSCA should validate the design in order to avoid runtime errors, and the membrane between design and runtime should be part of this validation.
I can think of two possible ways around this problem.
The first option is to eliminate inputs entirely. The idea is that operation executors are expected to have access to the entire service template representation -- they can pull whatever properties or attributes they want without having to call functions in the TOSCA service template source, and indeed have a much broader set of functionality than TOSCA intrinsic functions could ever have. This is what Cloudify does, by providing a CLI tool for bash and library calls for Python scripts to extract that contextual data. It's a far more powerful and comprehensive approach than inputs.
Does this mean that two different TOSCA orchestrators would not be mutually compatible in terms of their operational artifacts? Yes! But I'm certain that this would be the case today, too. And I am also certain that it is fine and good. Different implementations of TOSCA should compete on their implementations. The actual content of the implementation artifacts is purposely beyond the scope of TOSCA. TOSCA is about validating the design, and the basic design would otherwise be compatible. But how orchestrators actually do their is not something TOSCA should dictate, especially because it doesn't know what the future may bring.
The second option is a practical compromise: to allow inputs, but only at the node template level. So, inputs would be always undefined and not considered part of the contract. They would always be un-typed and ad hoc assignments, and it is left to the orchestrator to make sure that they are passed to the runtime in a non-breakable way. As shell environment variables? As db-stored values to be extracted via the API tools, just like they have access to the rest of the service template representation? Whatever. Inputs become an implementation detail, and as such can be put to use as necessary.
I don't think this is a necessary feature, because if the executors have access to the whole representation then they wouldn't need it. However, it also seems rather harmless to allow it as a kind of execution-scoped "user data" appended to the operation call. It could be used, for example, for call-specific metadata: e.g. an ssh user or certificate name for that particular call.
A variation of this second option would also allow ad hoc inputs at the node type level, with the understanding that those are still value assignments rather than definitions. They can be considered as default inputs, which could then be "overridden" at the node template. This makes sense in that we also allow artifacts to be attached to node types, as a kind of default implementation.
I'm leaning on the second option (or its variant). It provides an easier upgrade path from TOSCA 1.3, and seems useful and mostly harmless.
I think this an important change. It would eliminate the lack of clarity regarding what inputs are (they would no longer be "parameters", just raw assigned values), and would also clarify the contract implied by interfaces. Different operation names within an interface would still be atomic components of workflows, but their "inputs" would remain implementation details relevant to node templates and artifacts, rather than to the profile and the design models.
Final emphasis: I think it's good advice for TOSCA implementers to allow operation executors some kind of access to the entire service template representation. This could be clarified as part of the introduction. For those other cases, well, there can still be inputs!