Introduce update action in policy definitions

[lauwers]

Policy definitions current support the following actions in policy trigger definitions:

• delegate: to run a workflow defined elsewhere in the service template
• inline: to run a workflow defined inline
• call_operation: to invoke an operation on a node or relationship
• set_state: set node state

With the exception of set_state, none of these provide the ability for policies to make changes to the service representation graph, since workflows and operations interact with the external implementations only without modifying the representation first. This means that policies as currently defined are extremely limited in their usefulness.

To make policies more useful, I recommend that we introduce a new update action that can be invoked by policy triggers. The update keyword takes a set of updated input values with which to update the service representation. This would allow for true closed loop automation.

[pmjordan]

action is already a sequence of activities so why would you need to invoke another set below that to hold the updated input values? Could you not instead have a new action of set_input or have I misunderstood your intent?

[lauwers]

I believe the spec uses the terms action and activity interchangeably. This should get corrected.

More importantly, the intent is to have an action/activity that allows policies to update the representation graph. I don't believe that is possible with current grammar.

[pmjordan]

I've no object to the having an action which updates a value. I was just commenting on the sytax to achive that. I now see that we would need a keyword like update, as you suggest, e.g.
`activities:

• update:
  • <name_1>: <new_value_1>
  • <name_2>: <new_value_2>`

but inputs are only applied to properties when obtained with a $get_input function call. If you want the policy action to change the representation graph it seems the action would need to be on the property not the input. Perhaps the postion occupied by above should be a set_property call with the same structure as $get_property. If so then update would be better named set_properties

[lauwers]

Since inputs are the only externally-accessible aspects of a service that can be modified, one of the few ways to update a running service is to provide updated values for the service inputs. In response, the Orchestrator is expected to reevaluate the representation graph, which may involve re-fulfilling requirements (when node filters are no longer satisfied) or re-substituting nodes (when substitution filter are no longer satisfied). The discussion about the operational model refers to this in https://github.com/oasis-tcs/tosca-specs/blob/working/tosca_2_0/TOSCA-v2.0-csd07.md#44-changes-in-the-representation-graph-. The operational model as currently documented does not allow for external systems or human operators to modify node properties directly.