Allow distributing `service_template` among several TOSCA files

[tliron]

This tentative proposal is to allow a TOSCA file import tree to contain more than one file with a service_template keyname.

The obvious implication is that the final collection of entities will merge these separate definitions together. For example, the final node_templates collection will contain all node_templates in the tree, wherever they are defined. The final outputs will contain all outputs in the tree, wherever the are defined. As with types (node types, policy types, etc.) names must be unique and a name collision should be a syntax error. (An exception is policies, discussed below.)

Rationale:

1. Service design might be handled by a large team of humans. It could be difficult for everyone to work on one big file. Separating them via the imports feature seems reasonable and straightforward.
2. Designers don't have to be humans. A TOSCA file with node templates could be generated by a program. In such a case, it would be easy to combine the human-crafted templates with the machine-generated templates via imports.
3. Re-usability: an organization might have a part of the topology that is used a lot. imports can be preferable to copying-and-pasting. Note that that part of the topology might come with its own inputs and outputs that would also be merged into the final service.
4. The "why not" reason. TOSCA is modular regarding type entities, why not regarding template entities and parts of the topology?
5. Zero cost: if you don't like splitting up your templates among files, don't. It would have no cost for users who don't use it.

Alternative solutions and considerations:

1. If we allow imports to be used in this way we are potentially introducing another way to compose a service, moreover one that is entirely a design-time feature. Would this be confusing to users? I think not. imports is a very easy-to-understand concept. I don't think anybody would mistake it for deployment-time service compositions. Moreover, for some use cases deployment-time service composition might be unnecessary, because the relevant aspect of the topology is entirely determined by designers, and this thus would provide a much more straightforward and deterministic solution.
2. Re-usability can be achieved by creating types instead of importing templates. These types can have various default values, artifacts, interfaces, and other definitions. However, they cannot be specific about topology, e.g. a node type requirement definition cannot name a specific node template target. The point is that the imported file might not contain just a list of templates, but in fact be a complete, reusable "topology fragment". A second issue is that working with type grammar is different than working with template grammar, and going back to the above (several people working on designing the same service) this will demand that some people work with types instead of templates, even though they are designing templates.

Some implications:

1. Type names are namespaced and can be prefixed, e.g. "acme:Server". But template names are not namespaced. Thus the namespace feature of imports doesn't apply to these names. For example, if there is a node template named backup-host somewhere in the import tree, that would be its name, period. Thus designers have to be careful about name collisions, but this is very easy to verify via a simple design-time parsing tool.
2. policies is a bit different because it's a sequenced list rather than a map. Here we must have a more subtle merging rule. I propose that imported policies get simply appended after the current list. For example, if a TOSCA file defines 3 policies, and it also imports another file that has 2 policies, those 2 policies will be appended after the locally defined 3. This rule can be applied recursively.
3. This can remove the requirement that a service_template keyname exist in the root TOSCA file of a service. As long as templates are defined somewhere in the import tree, then they exist and that should suffice. (This does raise an interesting question, though: Should it be possible to define a service with no node templates at all? I don't see why not. Even right now we can create a service_template with no node templates.)

[lauwers]

I would be supportive of this proposal, as long as we mandate that each imported TOSCA service template should be valid when used stand-alone. Specifically, this means that one imported TOSCA file is not allowed to reference node templates by name that are not defined in the same TOSCA file.

[pmjordan]

@lauwers proposes the constraint 'should be valid when used stand-alone'. I suggest this would better be expressed as 'valid when considdered in isolation'. - Not every TOSCA template can be 'used' stand-alone but every TOSCA template should be valid.

[lauwers]

Yes @pmjordan , that is a much better articulation. Thanks!