OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] Event Interface Proposal


Hi Priya,

 

I realized I have not answered to your mail, I was hoping to discuss it all in the WG meeting before we go further. Anyway, some first thoughts on your proposals inline.

 

BR,

/Calin

 

From: <tosca@lists.oasis-open.org> on behalf of Priya T G <priya.g@netcracker.com>
Date: Tuesday, 7 August 2018 at 15:10
To: "lauwers@ubicity.com" <lauwers@ubicity.com>, Calin Curescu <calin.curescu@ericsson.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] Event Interface Proposal

 

Hello Calin, Chris,

 

This is regarding the event interface proposal  that was uploaded in OASIS portal recently:  https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/63289/EventInterface2018_06_20.docx   

 I believe this has not yet been discussed in TOSCA Simple Profile meetings, but  is in plan for TOSCA YAML v1.3.

I  have a few comments and suggestions on this:

 

  1. We could embed implementation artifacts in the  event_interfaces which could be responsible for triggering these events external to the Orchestrator. This is in addition to how information in such notification will be stored on node instances/topology instance attributes after it has been received.

 

I was thinking initially that the orchestrator will provide a couple of standard interface technologies (HTTP/REST, RPC, â) to accept these notifications, where the data model exchanged is YAML/JSON. So an external implementation would know exactly how to format data and use the API.

 

The only effect in the orchestrator is that attributes values are updated and specific orchestrator events are generated.  The events may then trigger workflows are already defined in TOSCA, and these workflows can then call operations that artifact implementations can be attached to. If we want to have a shortcut for the latter step (i.e. not needing to set up and specify an entire workflow), Iâm more inclined that we provide an extra âcall_operationâ keyword in the definition that will call a specific operation i.e:

         fault_report:

            outputs:

              name: fault

              value: [ SELF, monitor, failure ]

            event_types:

              - failure_processing

            call_operation:                        #new

            -  SELF.alarm_processing      #new    

 

  1. Just an alignment with common approaches like REST (when you can POST or wait for callback notification), we could rename âevent_interfaceâ as ânotificationâ

 

Notification is a good alternative. Letâs propose it to the group.

 

  1. Introduce a  new keyword âTOPOLOGYâ on similar lines as âSELFâ. This provides possibility to fill topology attributes as a result of an operation or event and provide possibility to read topology attribute values from node instances inside topology.

 

I donât think I understand the TOPOLOGY reference. Afaik, there are no attributes that are connected to the topology_template.

 

BR,

/Calin



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]