[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Event Interface Proposal
Calin, Thanks for responding. Clarifications below: 1.
I am actually referring to cases where artifacts associated with a node template could invoke the event interfaces, consider examples of scripts that could notify the Orchestrator upon some occurrence
of some events. In such cases, there should be a way to describe this artifact within the scope of node template. 2.
Regarding TOPOLOGY keyword,
in the current TOSCA Simple profile specification there are two cases how attribute is assigned a value from operation: a.
Attribute - by means of get_operation_ouput function in attribute definition/assignment b.
Operation â by means of output section Topology attributes can be filled through substitution mapping. We could adhere to a common approach and provide possibility to fill topology attributes through operation (or event) and read topology attribute
values from node instances inside topology. Let me know your views. Regards, Priya From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Calin Curescu 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> 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:
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
Notification is a good alternative. Letâs propose it to the group.
I donât think I understand the TOPOLOGY reference. Afaik, there are no attributes that are connected to the topology_template. BR, /Calin
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]