RE: [tosca] Event Interface Proposal

[Chris Lauwers <lauwers@ubicity.com>]

Comments in-line:

 

From: Calin Curescu [mailto:calin.curescu@ericsson.com]
Sent: Thursday, October 04, 2018 7:15 AM
To: Priya T G <priya.g@netcracker.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
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