[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Event Interface Proposal
Hi Calin, Thanks for putting this together. This is excellent work. Adding support for asynchronous notifications will increase the usefulness of TOSCA tremendously, and it will allow us to integrate policies and workflows much more cleanly into
the rest of the orchestration logic. I have one main comment on your proposal, and a couple of smaller observations about specifics of the syntax.
Thanks again for taking the initiative to write this contribution. Letâs discuss next week so we can make this an important part of the 1.3 specification. Chris From: Calin Curescu <calin.curescu@ericsson.com> Dear all, Based on the suggestion from Priya I have renamed the âevent callâ to ânotificationâ and based on Chris proposal I have included the notifications as a section in a generic Interface definition. I have submitted a new proposal document
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/63994 We still need to discuss the 2 comments from Priya:
Priya: Please review my answers with green in the mailthread below. BR, /Calin From:
Chris Lauwers <lauwers@ubicity.com> Yes, I had assumed that ânotificationsâ or âeventsâ would be grouped under their own keyword to keep them separate from the operations. In fact, my parser creates an âoperationsâ grouping behind the
scenes to gather the various operations. Iâm all for making this explicit in the spec and obsolete the current practice of defining operations at the same level as the âinputsâ keyword. Thanks, Chris From: Calin Curescu [mailto:calin.curescu@ericsson.com]
Chris: Sure. However the reader should be aware of the important difference here:
Then I would lobby to introduce in the interface definition the keyword âoperationsâ to gather the operations symbolic name and the keyword ânotificationsâ to gather the notifications symbolic names. Anyway the former is already required since not having it clashes with the âinputsâ section of the interfaces (see matt comment in section 3.7.5.2. Grammar of Interface Type Definitions). Priya: please fins some inline comments in your text below. Btw, I think the ânotificationâ name fits very well, so I will use that from now on. BR, /Calin From:
Chris Lauwers <lauwers@ubicity.com> I like these concepts, but Iâd like to avoid having to create new âinterface typesâ just for events or notifications. We already have too many types of types. Canât we just add a notifications or events keyname to the existing interface definitions? Chris From: Priya T G <priya.g@netcracker.com>
Calin, Thanks for responding. Clarifications below:
What I mean is that anybody can invoke the notifications, the association with the artifact is not useful since we are just exposing an API here.
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. In the case of substitution mapping, the properties of the substituted node are mapped to the inputs of the substitution topology template, and the outputs of the topology template
are mapped back to the attributes of the substituted node. So we could use the outputs here, where they could get assigned using get_attribute from a specific node. Then we do not need the TOPOLOGY keyword (and anyway there are no
global attributes section of a topology template. 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]