TOSCA functions inside policy definitions

[lauwers]

I have a need to define event/condition/action policies in TOSCA using the policy definition syntax. I'm running into a couple of issues:

• I'd like to make the policy definitions configurable using policy properties, but our current TOSCA Path syntax does not provide a mechanism for accessing policy property values.
• The condition clause in policy triggers specifies a Boolean function that itself may need to access property values within the service, including property values specified in the policy definition. The spec is unclear about the context within which these functions are evaluated (i.e. what is the meaning of SELF within a policy). I see three options:
  1. The service within which the policy is defined. In this case, the keyword SELF is not supported.
  2. The target node that generated the event that triggered the policy action (i.e. SELF refers to that target node).
  3. The policy itself (i.e. SELF refers to the policy).

I propose the third approach, where SELF refers to the policy. That would all the different use cases:

1. $get_property: [SELF, threshold]: This accesses the value of a property named threshold within the policy
2. $get_attribute: [SELF, TARGET, utilization]: This accesses the value of an attribute named utilization within the target node that generated the event. Note that this would be a new use for the TARGET keyword in TOSCA Path.
3. $get_property: [server, max_capacity]: This accesses the value of a property named max_capacity in a node named server in the service that defines the policy.

[pmjordan]

On first reading I found it confusing that the node which generates an event can be referred to as the TARGET. This is correct since we define policies as being targetted at nodes but if TARGET is to be used this way it would need to be explained.

[lauwers]

Yes, the policy grammar is very confusing:

1. Policies were originally specified in TOSCA Simple Profile in YAML v1.0. They assumed declarative policies that are intended to define conditions that must apply either to the service as whole or to nodes defined in the list of targets. The spec describes examples such as anti-colocation policies (where all the nodes in the list of targets have to be deployed on different hosts). Unfortunately, the 1.0 spec does not define any grammar for the policy conditions that must hold true.
2. Simple Profile in YAML v1.1 introduced policy triggers. Triggers are imperative policies that define event/condition/action tuples, but unfortunately the 1.1 spec lacks clarity on which events need to be handled or where events are expected to be received from. The 1.1 policy definition keeps the targets keyword, which presumable defines the list of nodes that generate the events to be handled by the triggers. Unfortunately, the 1.1 spec does not include any examples of policy triggers.
3. Simple Profile in YAML v1.3 tries to formalize events by defining interface notifications that define events that can be generated for nodes and relationships, but again this is done without supporting examples.

None of this is very well thought through, and more work is required to get this in decent shape.