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 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.

 

  1. My main comment has to do with the use of âevent typesâ as part of a ânotification definitionâ. I had assumed that the ânotificationâ itself would define the event, and that the name of the notification would be used directly in the âevent_typeâ section of a policy trigger. What is the motivation for introducing a separate event_type, rather than re-using the notification name itself? Are you introducing event types strictly to satisfy the (already existing) policy grammar? If so, I would prefer to not introduce any unnecessary concepts and instead just re-use the notification name itself.
  2. A couple of other comments:
    1. It would be helpful to give examples of ânotification implementationsâ using artifacts. I assume that ânotificationâ grammar will just re-use the existing âoperation implementationâ grammar, but we need to make sure weâre not missing anything.
    2. Your examples show a difference between âoutput definitionsâ and âoutput assignmentsâ. However, the operation output grammar we decided on does not make such a distinction. Instead, it only uses âoutput assignmentsâ (or âattribute_mappingsâ to be correct), both in node templates and node types, as shown in Section 3.16.17. (However, I just noticed that section 3.16.17.2.3 in the latest 1.3 draft doesnât include operation output support in node templates, even though section 2.15 shows examples of this. Iâll fix this in a future draft)
    3. You include an example of a âcallbackâ that provides a node and a callback notification as inputs to an operation. Wouldnât it be cleaner to support this use case by defining a new âasynchronousâ lifecycle management interface where a separate âon_successâ notification is defined for each operation. Using the asynchronous interface, operations would return immediately (indicating that the operation has been started), and then the âon_successâ for that operation is called as soon as the operation completes. The âcallbackâ would then be implemented using the âpolicy triggerâ support that is already part of the language.
    4. I notice youâre reading the âpolicy triggerâ grammar in the spec differently than I did: in your examples triggers are named. I didnât think the spec included trigger names. Of course, since there are no policy examples in the spec and the grammar itself is ambiguous, it is hard to know which is correct. Iâm currently working on a project that requires TOSCA policies, and I must admit I find the whole policy section confusing. I would love a separate discussion on policies after we talk about notifications.
    5. On a related note, there are a lot of similarities between âpolicy triggersâ and âworkflow stepsâ, especially in the area of defining (pre)conditions. At the same time, there are enough syntax differences to make it difficult to keep the concepts straight. I think there is an opportunity to clean things up here.

 

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>
Sent: Tuesday, October 02, 2018 7:23 AM
To: Chris Lauwers <lauwers@ubicity.com>; Priya T G <priya.g@netcracker.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Event Interface Proposal

 

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:

  • The TOPOLOGY keyword
  • The artifact connection

 

Priya: Please review my answers with green in the mailthread below.

 

BR,

/Calin

 

From: Chris Lauwers <lauwers@ubicity.com>
Date: Thursday, 20 September 2018 at 02:57
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

 

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]
Sent: Tuesday, September 04, 2018 6:17 AM
To: Chris Lauwers; Priya T G
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Event Interface Proposal

 

Chris: Sure.

 

However the reader should be aware of the important difference here:

  • The normal operation is invoked internally from the orchestrator during LCM workflows
  • The notification is invoked any time by the external world.

 

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>
Date: Monday, 3 September 2018 at 07:10
To: Priya T G <priya.g@netcracker.com>, Calin Curescu <calin.curescu@ericsson.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: RE: [tosca] Event Interface Proposal

 

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>
Sent: Friday, August 31, 2018 6:44 AM
To: Calin Curescu <calin.curescu@ericsson.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
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.

 

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.

 

  1. 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.

 

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
Sent: Wednesday, August 29, 2018 7:59 PM
To: Priya T G; lauwers@ubicity.com
Cc: tosca@lists.oasis-open.org
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

 


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]