RE: [tosca] Event Interface Proposal

Comments in-line:
 


From: Calin Curescu [mailto:[email protected]]

Sent: Thursday, October 04, 2018 7:15 AM
To: Priya T G <[email protected]>; Chris Lauwers <[email protected]>
Cc: [email protected]
Subject: Re: [tosca] Event Interface Proposal


 
Hi Priya,
 
1. With regards to the implementation artifact I saw your previous answer but I never quite got it until now. This because I thought of notifications like an API (RPC, REST, etc.) of the orchestrator that everybody
in the outside world may call.  In that case, no need to specify and artefact, the orchestrator accepts notifications from everywhere.
 
Now I got it. Maybe my proposal was too open, so we would like to receive notifications/callbacks only from a specific artifact that is included in the CSAR and specified in the implementation. Thus, we don t have
to somehow publish the node or notification name to the external  world, it is associated to the artifact when the orchestrator processes the implementation keyword, like for operations.

 
So security is better, and the target for the notification automatically associated to the artifact. So I guess then we should use an implementation artifact.
 
I see that artifact definition as no different at all from the ones used for operations.
 
Yes, that was my thinking as well. This introduces a new requirement for artifact processors, however: for each Artifact Type (and as
a result for each Artifact Processor) we need to define how the Processor calls back into the Orchestrator to generate the notification. For example, let s assume a notification has an implementation artifact that is a shell script that periodically polls
the status of a piece of equipment. When the shell script obtains the result, how does it communicate it back to the orchestrator in a way that generates a notification?
 
2. With regards to TOPOLOGY I cannot see how that can be implemented, as there are no attributes of the template to map the outputs to.

 
So I guess your proposal refers to substitution mappings. And this is a very good concern indeed.
 
So, the operations of a top-level node map to workflows in the substitution template. Then notifications of the top-level node should also map to workflows in the substitution template. With the difference that:

-          
These workflows have no inputs as they are not called by a workflow in the top-level template

-          
These workflows are triggered within the substitution template when some conditions happen


o   
This trigger is specified in a policy in the substitution template


 
Either as a specific attribute change

 
Or when a notification of a node in the substitution template arrives.

o   
The output of this workflow is then sent to the top-level node as the mapped notification output


 
In the same way as for the new operation outputs
 
Now, we have not defined workflow outputs (that we need also for the new operations substitution mapping).
 
I propose to add an outputs keyword to the workflow definition. And the outputs will be assigning a get_attribute function (with the full scope of the template nodes).
 
After we define events and clean up policies and workflows, we should then revisit how this fits into substitution mapping. Workflows,
operations, notifications, and policies are all about the flow of control horizontally within a service topology. The question we need to answer is how control flows vertically between an abstract node and a substituting service topology for that abstract
node. Lots of unanswered questions. For example, the current substitution mapping specifies mappings between the create operation on an abstract node and the deploy workflow of the substituting topology. But what happens to the configure and start operations
of the abstract node?
 
Chris
 
 
BR,
/Calin