RE: rules for TOSCA intrinsic functions

[Priya T G <priya.g@netcracker.com>]

Chris,

 

Apologies for the delay and for shuffling the order of items in your original email.

 

1.       Regarding the following and in the context of last week’s discussion regarding passing inputs to workflows:

 

When assigning input values to interface operations, we should avoid using get_input functions that retrieve values directly from topology template inputs. It is better to first reflect topology template inputs into node properties, and then use get_property instead in operation input assignments. That way, we avoid “bypassing” the topology model when calling interface operations.

 

Quite often, topology inputs are used to control a particular operation implementation, for passing some temporary variables that need not be a part of the topology instance model. It would be an overkill to describe such variables as properties of node type/node template.

 

2.       Regarding the additional rules i.e. use of ONLY SELF, SOURCE and TARGET keywords in get_attribute and get_property functions, such checks could be done by the TOSCA parser to inform the user that it is not possible to reference a particular node template because of provisioning order. The current grammar can be left as it is.

 

3.       Regarding use of intrinsic functions in constraint definitions in node_filters, since node_filter matching is done before run time, it makes sense to not allow get_attribute and get_attribute for reasons that you have summarized in your email.

 

4.       Regarding the assigning of attribute values to property values, we need this feature for the following case:

 

-          When we have two topologies, each represented as topology templates

-          When a parent template is present, representing these topology templates as abstract node templates having a dependency on each other

-          When there is a need for passing the output of the first topology as input to the second topology template

 

A typical example could be a database (with some constituent nodes represented as a topology) connected to a web server (represented as a topology) where the database IP address is required for creation/configuration of the web server.

 

.

 

Regards,

Priya

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Chris Lauwers
Sent: Tuesday, July 2, 2019 9:59 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] rules for TOSCA intrinsic functions

 

[External Email]

---

 

In the context of an editors’ meeting between myself and Calin, we discussed a number of questions related to the use of intrinsic functions. In particular, we debated Example 17 in the v1.3 specification (in Section 2.11.1). This example shows the following snippet:

 

    trans1:

      type: example.TransactionSubsystem

      properties:

        mq_service_ip: { get_attribute: [ mq, service_ip ] }

 

We believe the highlighted property assignment (for the mq_service_ip property) has a couple of issues:

1. Since mq_service_ip is a property, it defines initial configuration information that must be provided before a service instance can be instantiated. However, in this example this property value is initialized using a get_attribute intrinsic function. Attributes (by definition) represent run-time information that is not available until after the service instance has been created, configured, or started (depending on which operation sets the value of the attribute in its output mappings). What this illustrates, in my opinion, is that attribute values cannot be used to initialize property values.
2. In addition, the get_attribute function attempts to retrieve the attribute value from the “mq” node. However, the “mq” node has a relationship to the “trans1” node (as you’ll be able to see from the full Example 17 snippet). Because of the directionality of this relationship, the orchestrator will instantiate the “trans1” node before it instantiates the “mq” node. This means that the get_attribute function call will always fail, because it will reference a node that will not exists.

What this illustrates is that without some additional “rules”, the use of intrinsic functions could potentially result in incorrect service templates. Calin and I discussed some potential rules. For example:

 

1. It is illegal to use get_attribute to set a property value.
2. We believe we should not allow get_attribute and get_property functions to “target” arbitrary nodes in a topology template. Instead, nodes should only be allowed to retrieve values from those nodes with which they have a relationship (by traversing the topology graph). In practice, this means that we should only allow SELF, SOURCE, and TARGET keywords as allowed values to identify nodes in get_attribute and get_property functions.

 

In addition, there are a couple of areas where we should recommend “best practices”:

1. When assigning input values to interface operations, we should avoid using get_input functions that retrieve values directly from topology template inputs. It is better to first reflect topology template inputs into node properties, and then use get_property instead in operation input assignments. That way, we avoid “bypassing” the topology model when calling interface operations.
2. We discussed the use of intrinsic functions in the constraint definitions used in node filters, as in the following example:

    requirements:

-    host:

        node_filter:

          capabilities:

          - os:

              properties:

                - architecture: { get_input: os_architecture }

                - type: { get_input: os_type }

This is a very useful construct, since it allows external APIs to drive resource selection by specifying the appropriate input values. However, this raises the question of whether the use of get_property or get_attribute should also be allowed. I believe it should be clear that get_attribute calls should not be allowed, since that would mean that resource selection is based on run-time information, which is not something I believe we want to do. Get_property calls could make sense, but get_property calls could access properties from other nodes, including nodes that are referenced using dangling requirements. This means that depending on the order of the requirements, get_property may try to access a node that hasn’t been “selected” yet.

 

I’ll add this topic to the agenda of one of our future TOSCA Language Ad-Hoc WG meetings.

 

Thanks,

 

Chris

 

---

The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.