rules for TOSCA intrinsic functions

[Chris Lauwers <lauwers@ubicity.com>]

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