Re: [tosca] Event Interface Proposal

Hello,

More inline.

From: Chris Lauwers <lauwers@ubicity.com>
Date: Thursday, 4 October 2018 at 23:16
To: Calin Curescu <calin.curescu@ericsson.com>, Priya T G <priya.g@netcracker.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: RE: [tosca] Event Interface Proposal

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?

I see the same issues as for the operation implementation artifact, ie. the orchestrator knows how to find it, connect to it, communicate to it (in the sense that for notifications it will register as a call-back or use polling) but in the end the same applies as to operations artefacts (repeating): 1) make sure itâs the right one: mime/type, version, 2) make sure itâs no error: checksum, checksum-algorithm 3) any other attribute: as artefact attributes

We could though define a sort of format for the exchanged information between the orchestration and artefact. E.g. the information exchanged (both ways) is a set of name-value pairs. While for the orchestration -> artefact part is enough to have the input name and value, for the return we could accept some extra information from the artefact dealing with the outcome such as:

success: true | false (a boolean value if return was successful or not)

additional_information: an additional map of key-value pairs (if the artefact wants to communicate it)

Of course in the case of failure it could be that the orchestrator never got something correct (in time or format):

The orchestrator never got the info back in time:

timeout: true

if could not connect in the first place:

connection_error: true

if they could not understand each other:

protocol_error: true

or if the data received could not be understood:

format_error: true

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?

Sure, we can wait, but we need eventually to specify how a substitution deals with a notification in the abstract node. I think that it will also map to a workflow as an operation does.

Also, we could without problems use todayâs workflows to do that (and map the outputs via the substitution mappings), but I believe it would be nice to define an âoutputsâ section in the workflow. Today workflows use the outputs of the topology_template which is quite messy and not well specified.

Chris

BR,

/Calin

tosca message