Clarification on usage of TOSCA grammar to define objects in Metadata

[abhishek-kumar0409]

As it is evident from the standards, the data type of the metadata is a map of strings. I've come across some VNF Descriptors that use map of strings along with expressions as shown in the below example.

e.g.

input:
    security_group_0: "default"
    security_group_1: "custom"
node_template:
    vdu_a
        type: tosca.nodes.x.y.z.
        properties:
             k1: v1
        metadata:
            security_groups: { get_input: security_group_0}

In this example, the assumption is made that the security group is pre-created by the cloud administrators. And, the VNF-D designer has to simply reference the name of the security group name in the VNF-D, without creating the security groups in the Openstack. Some designers may use inputs section to define the value of the security group or any other k-V parameters and use get_input property to .

Perhaps it is not evident for the TOSCA grammar whether the objects defined in the metadata section is map of strings or map of strings with expression.

Question - Is it allowed to define values as map of string with expressions in the metadata ?

[ahanniga]

Hi @abhishek-kumar0409 ,

The metadata node is not important here. I think the question can be summarised as:

"Is it permitted to use TOSCA functions such as get_input outside of a properties node".

This applies the node_template as a whole, rather than individual nodes

[lauwers]

The short answer is yes. In general, it is legal to use function values anywhere in a template (or a profile) where a value needs to be specified (although there are a number of exceptions). TOSCA v1.3 does not do a very good job of detailing this, but we're trying to be much more precise in TOSCA v2.0 If you look at Section 6.1 of https://www.oasis-open.org/committees/document.php?document_id=70220&wg_abbrev=tosca, you'll see that we're starting to spell out the rules for where function values are allowed. We're working on defining where function values are not allowed in detail as well. I believe the team is currently on the fence regarding function values in metadata.

[daveywebster]

Thanks Chris, in light of explicit advice, then my opinion is that if we are compliant to the TOSCA v1.3 specification, then as get_input isn't explicitly forbidden in the context described (in this version of the specification), that there would be no restrictions in the given context.

This may change in the future (for example, TOSCA v2.0), but for the moment, it should not be considered "illegal" to use get_input under the metadata as shown by the example by "Abhishek" and commented on by "Aidan".

If that interpretation is incorrect, then please let us know.

Much thanks.
Dave

[abhishek-kumar0409]

Many thanks @lauwers (for ensuring that these issues are being addressed in your future work) , @ahanniga (for simplifying my question).

@lauwers: Can you provide us some guidance on interpretation of the grammar in the existing standards ?

As per section 3.10.3.2 metadata (TOSCA-1.3), This keyname is used to associate domain-specific metadata with the Service Template. The metadata keyname allows a declaration of a map of keynames with string values.

This clause in TOSCA-1.3 spec seems to contradict with the statements made above.

Regards,
Abhishek

[tliron]

I do not think metadata should support function calls.

The issue is that metadata is essentially structural. It is associated with almost all TOSCA entities, which includes types, but if it must be dynamically rendered (with calls to get_input or get_attribute) then there is no way to store this metadata as part of the structure. To support such dynamic metadata, every TOSCA service instance would have to allow for entirely different metadata for all types -- including types imported from profiles. Thus, sharing metadata between instances is also impossible. To me this goes against the whole point of metadata, which is structural annotation. In other words, metadata is for the "node template", not the node instance.

Your example would support my point. It seems you are using metadata to provide extra properties/attributes that were not included in the node type, essentially working around deficiencies in the profile. But, notice another problem: TOSCA values are marked as either "properties" or "attributes", with different runtime and storage semantics. How do you expect metadata to work? Like a property, or like an attribute? This is undefined and, I argue, shouldn't be defined.

Alternative solutions would be:

1. inherit the node type and add a security_groups property or attribute.
2. use a group or a policy to associate additional properties to one or more nodes.
3. use a preprocessor to generate the TOSCA service template with the right metadata.

I admit, these three alternatives are all more challenging than simply adding more properties/attributes. If this use case seems prevalent, I would propose we discuss an addition to TOSCA 2.0:

An extra_properties keyname allowing for ad hoc properties to be attached to any node template, group, policy, relationship, and capability. (And possibly an extra_attributes where applicable.)

This might seem scary because these extra properties and attributes have not been declared and are thus non-typed. However, let's remember that we allow for undeclared (non-typed) values as operation inputs and service template outputs.

I'm not excited about such an addition because it is very rife for abuse. Essentially all type information can be ignored. Imagine all your node templates being of Root type and using extra_properties exclusively. I don't think it's what we want to see in TOSCA.

However, I likewise do not think we want to see metadata being abused as a way to provide such "extra properties".

[philippemerle]

I fully agree with @tliron : metadata should be seen as annotations attached to TOSCA elements (e.g. types, node templates), and should not be seen as properties or attributes of type/template instances.

According to section 3.6.2.2, the grammar defines that metadata is a map of strings, the grammar does not define that metadata is a map of string expressions.

According to section 3.6.2.4, "Data provided within metadata, wherever it appears, MAY be ignored by TOSCA Orchestrators and SHOULD NOT affect runtime behavior.". In the given example, the security_groups metadata seems to break the previous sentence as this metadata will be used to configure a runtime characteristic of the VNF node instance. security_groups should be better 1) a property (if the designer intent is to define a desired value) or an attribute (if the intent is to define an actual value).

[lauwers]

I believe we decided that the specification should state explicitly where function values are allowed. https://docs.oasis-open.org/tosca/TOSCA/v2.0/csd05/TOSCA-v2.0-csd05.html#_Toc125468800 starts to do this, but the language in that section is somewhat wishy-washy. It should be cleaned up.

[lauwers]

The consensus is that function values are not allowed in metadata. Issue #139 will be used to further define the areas in the spec where function values are explicitly allowed.