Syntactical sugar for generating templates

I think we've moved forward a bit in the last ad-hoc meeting.

I'm still skeptical about the need for multiplicity at the design level of TOSCA, and more importantly very wary about the added complexity and confusion that this would surely foster.

However, I've reached some peace with it as long as I can consider it as syntactic sugar for generating node templates during processing. As I said in the meeting, I would be OK (sorta) as long as we're not adding an extra ID management system to TOSCA. That means: we should insist on only dealing with node template names as a way for identifying node templates.

My rough feature proposal here is called "variability" and involves three new additions:

1) Node template names could be values rather than just string literals. I don't see any immediate problem with this in terms of TOSCA processing. So, this means that node template names could be generated by calling functions. You could, for example, do a get_input to get the node template name externally. That ... is not very useful. More useful is a new function mentioned below.

2) The new "get_variable" function would allow extraction from designer-created variables. It otherwise follows the conventions of get_property and get_attribute in terms of path following.

3) The new "variables" keyword in node templates allows for the creation of custom variables within the scope of the node template, for use with the above get_variable function. Crucially, variables do not have to be single values. The "list" or "map" keywords can be used to iterate across zero or more values. Thus we create the "variability" feature.

An example of how to put these together:

topology_template:

Â inputs:

ÂÂÂ sites:

ÂÂÂÂÂ type: list

ÂÂÂÂÂ entry_schema: Site

ÂÂÂÂÂ default:

ÂÂÂÂÂ - name: new-york

ÂÂÂÂÂÂÂ size: 100

ÂÂÂÂÂ - name: tokyo

ÂÂÂÂÂÂÂ size: 200

ÂÂÂÂÂ - name: berlin

ÂÂÂÂÂÂÂ size: 200

Â node_templates:

ÂÂÂ host:

ÂÂÂÂÂ type: Server

ÂÂÂÂÂ requirements:

ÂÂÂÂÂ - location:

ÂÂÂÂÂÂÂÂÂ node: site-tokyo

ÂÂÂ { concat: [ site-, { get_variable: [ SITE, name ] } ] }:

ÂÂÂÂÂ type: DataCenter

ÂÂ ÂÂ properties:

ÂÂ ÂÂÂÂ size: { get_variable: [ SITE, size ] }

ÂÂ ÂÂ variables:

ÂÂÂÂÂ - name: SITE

ÂÂ ÂÂÂÂ list: { get_input: sites }

This should be fairly clear. We're going to have three node templates generated for us: "site-new-york", "site-tokyo", and "site-berlin".

Obviously, the most awkward part of this is using a function call instead of the node template name. I'll remind everybody that this is perfectly valid YAML! (Although it's uncommon to use non-string keys from maps.) It does mean that TOSCA processors would have to coerce node template names into their actual values before constructing the topology. (As I said, I think this whole feature would be cumbersome any way we skin this cat.)

You might be worried that the "host" node template's requirement specifies the generated node template name, which might not be known in advance (and if it's not there we would get a processing error -- template not found). Well, as you know, it could also be a node type name instead. So we can write this:

ÂÂÂ host:

ÂÂÂÂÂ type: Server

ÂÂÂÂÂ requirements:

ÂÂÂÂÂ - location:

ÂÂÂÂÂÂÂÂÂ node: DataCenter

in which case it would match with any of the generated node templates of that type. But ... what if we don't want to match with just any DataCenter, we want to match with the specific "group" of templates created by that variability? So, here's another proposed version of this grammar that can fix that (yes, it goes beyond syntactical sugar):

ÂÂÂ host:

ÂÂÂÂÂ type: Server

ÂÂÂÂÂ requirements:

ÂÂÂÂÂ - location:

ÂÂÂÂÂÂÂÂÂ node: sites

ÂÂÂ sites:

ÂÂÂÂÂ aliases:

ÂÂÂÂÂ - { concat: [ site-, { get_variable: [ SITE, name ] } ] }

ÂÂÂÂÂ type: DataCenter

ÂÂ ÂÂ properties:

ÂÂ ÂÂÂÂ size: { get_variable: [ SITE, size ] }

ÂÂ ÂÂ variables:

ÂÂÂÂÂ - name: SITE

ÂÂ ÂÂÂÂ list: { get_input: sites }

In this version, we have the new "aliases" keyword that allows us to give extra names for the variable node templates (or really any node template, including non-variable ones). There are two implications for this:

1) Node templates can have more than one name. In this example we'll have a node template that is called both "sites" and "site-tokyo".

2) Node template names can refer to more than one template! The name "sites" refers to three node templates: "site-new-york", "site-tokyo", and "site-berlin".

While this version adds complexity to how we construct our template namespace (many-to-many), it's well-defined. A node template name can refer to more than one node template. Also, it avoids the awkward YAML we had in the first version.

Note that this also allows for giving two "different" node templates the same alias. Is this a problem? I don't think it is. Actually, it could allow for some more flexibility in specifying requirements. Example:

ÂÂÂ host:

ÂÂÂÂÂ type: Server

ÂÂÂÂÂ requirements:

ÂÂÂÂÂ - location:

ÂÂÂÂÂÂÂÂÂ node: site

ÂÂÂ site1:

ÂÂÂÂÂ aliases:

ÂÂÂÂÂ - site

ÂÂÂÂÂ type: DataCenter

ÂÂÂ site2:

ÂÂÂÂÂ aliases:

ÂÂÂÂÂ - site

ÂÂÂÂÂ type: DataCenter

The aliases here function as a kind of tag to allow us to to group node templates together. In this sense it almost replaces the "group" grammar by providing a different way to associate node templates together.

tosca message