OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define attributes on
topologies?
 
Thanks,
 
Chris
 


From: Priya T G <priya.g@netcracker.com>
Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 


For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop) that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 


The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider  a VNF described using a topology template.  While the availability of VDUs can
be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

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

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.
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).
 
BR,
/Calin
 

From: Chris Lauwers <lauwers@ubicity.com>
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define attributes on
topologies?
 
Thanks,
 
Chris
 


From: Priya T G <priya.g@netcracker.com>
Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 


For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop) that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 


The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider  a VNF described using a topology template.  While the availability of VDUs can
be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

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?
 
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?
 
Chris
 
 
BR,
/Calin

Hello,
 
More inline.
/C
 

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

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [mailto:calin.curescu@ericsson.com]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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


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.
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).
 
BR,
/Calin
 

From:
Chris Lauwers <lauwers@ubicity.com>
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define
attributes on topologies?
 
Thanks,
 
Chris
 


From: Priya T G <priya.g@netcracker.com>

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop)
that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider
 a VNF described using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  


 



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.
 

Hi Priya,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs) For the old-style operations, which had no outputs defined, this mapped fine Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

We map the notification output still to the local node attribute Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract
node operation/notification and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [mailto:calin.curescu@ericsson.com]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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


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.
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).
 
BR,
/Calin
 

From: Chris Lauwers <lauwers@ubicity.com>
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define attributes on
topologies?
 
Thanks,
 
Chris
 


From: Priya T G <priya.g@netcracker.com>
Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop) that check some
parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider  a VNF described
using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  
 



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.  

Calin,
 
Apologies for the delay. Thank you for the clarification,  I agree that your proposal is an alternative for the TOPOLOGY keyword.
However, I would like to introduce an additional use case to demonstrate the need for this keyword. Sorry if this is a digression from the topic that is currently under discussion.

 
Consider a case of retrieving a fully qualified custom name for a node instance for e.g.
super_vnf1-vSRX .  It is not possible to feed this VNF name as topology input because all instances of the VNF will receive the same set of  input parameters.
If such a VNF node template in the NS descriptor has the VNF name as an attribute, then the TOPOLOGY keyword can help to retrieve this,  based on the VNF and VDU names as depicted below:
Let me know.
 
Regards,
Priya
 
 
 

 


From: Calin Curescu [mailto:calin.curescu@ericsson.com]

Sent: Tuesday, October 9, 2018 5:31 PM
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,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

-          
In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template

-          
Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs)

-          
For the old-style operations, which had no outputs defined, this mapped fine

-          
Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

-          
We map the notification output still to the local node attribute

-          
Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute

-          
The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  
        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract node operation/notification
and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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


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.
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).
 
BR,
/Calin
 

From:
Chris Lauwers < lauwers@ubicity.com >
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define
attributes on topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop)
that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider
 a VNF described using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

 



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.  

 



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.
 

Hi Priya,
 
I don t know if I understand your example. Let me see:
 
If you cannot model the name of the VNF in the NS template as a property (since it will not be available at template parsing time), then it must be an attribute.

 
This also means that there has to be a way (operation, notification) that will give you this name as an output.
 
But since you have already substituted the node type with the substitution topology, you can receive this name directly in the substitution topology template via an operation or notification in the substitution template
to which the original operation or notification was mapped via substitution mappings.

 
Again, I don t know if I understood it well.
 
BR,
/Calin
 
 

From: <tosca@lists.oasis-open.org> on behalf of Priya T G <priya.g@netcracker.com>
Date: Tuesday, 30 October 2018 at 14:36
To: Calin Curescu <calin.curescu@ericsson.com>, Chris Lauwers <lauwers@ubicity.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: RE: [tosca] Event Interface Proposal


 

Calin,
 
Apologies for the delay. Thank you for the clarification,  I agree that your proposal is an alternative for the TOPOLOGY keyword.
However, I would like to introduce an additional use case to demonstrate the need for this keyword. Sorry if this is a digression from the topic that is currently under discussion.

 
Consider a case of retrieving a fully qualified custom name for a node instance for e.g.
super_vnf1-vSRX .  It is not possible to feed this VNF name as topology input because all instances of the VNF will receive the same set of  input parameters.
If such a VNF node template in the NS descriptor has the VNF name as an attribute, then the TOPOLOGY keyword can help to retrieve this,  based on the VNF and VDU names as depicted below:
Let me know.
 
Regards,
Priya
 
 
 

 


From: Calin Curescu [mailto:calin.curescu@ericsson.com]

Sent: Tuesday, October 9, 2018 5:31 PM
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,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs) For the old-style operations, which had no outputs defined, this mapped fine Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

We map the notification output still to the local node attribute Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  
        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract node operation/notification
and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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


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.
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).
 
BR,
/Calin
 

From: Chris Lauwers < lauwers@ubicity.com >
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define attributes on
topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop) that check some
parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider  a VNF described
using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  
 



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.  
 



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.  

Calin,
 
Apologies for the delay.  Regarding your response below,  the example is related to VNF instance name rather than VNF name and thus, it has to be an attribute.
For  retrieving a fully qualified custom name of a VDU,  the TOPOLOGY keyword helps to retrieve the VNF instance name associated with the VDU.
This is not related to notification as such, I was just attempting to demonstrate the need for TOPOLOGY keyword since you suggested another way ( snippet below )
for mapping the attributes in topology template to the abstract node template.
Did I clarify? Please let me know.
 
Regards,
Priya
 
We can still use this as it is for notifications:

-          
We map the notification output still to the local node attribute

-          
Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute

-          
The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 


From: Calin Curescu [mailto:calin.curescu@ericsson.com]

Sent: Thursday, November 1, 2018 8:57 PM
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,
 
I don t know if I understand your example. Let me see:
 
If you cannot model the name of the VNF in the NS template as a property (since it will not be available at template parsing time), then it must be an attribute.

 
This also means that there has to be a way (operation, notification) that will give you this name as an output.
 
But since you have already substituted the node type with the substitution topology, you can receive this name directly in the substitution topology template via an operation or notification in the substitution template to which the original
operation or notification was mapped via substitution mappings.
 
Again, I don t know if I understood it well.
 
BR,
/Calin
 
 

From:
< tosca@lists.oasis-open.org > on behalf of Priya T G < priya.g@netcracker.com >
Date: Tuesday, 30 October 2018 at 14:36
To: Calin Curescu < calin.curescu@ericsson.com >, Chris Lauwers < lauwers@ubicity.com >
Cc: " tosca@lists.oasis-open.org " < tosca@lists.oasis-open.org >
Subject: RE: [tosca] Event Interface Proposal


 

Calin,
 
Apologies for the delay. Thank you for the clarification,  I agree that your proposal is an alternative for the TOPOLOGY keyword.
However, I would like to introduce an additional use case to demonstrate the need for this keyword. Sorry if this is a digression from the topic that is currently under discussion.

 
Consider a case of retrieving a fully qualified custom name for a node instance for e.g.
super_vnf1-vSRX .  It is not possible to feed this VNF name as topology input because all instances of the VNF will receive the same set of  input parameters.
If such a VNF node template in the NS descriptor has the VNF name as an attribute, then the TOPOLOGY keyword can help to retrieve this,  based on the VNF and VDU names as depicted below:
Let me know.
 
Regards,
Priya
 
 
 

 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, October 9, 2018 5:31 PM
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,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

-          
In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template

-          
Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs)

-          
For the old-style operations, which had no outputs defined, this mapped fine

-          
Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

-          
We map the notification output still to the local node attribute

-          
Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute

-          
The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract node
operation/notification and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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


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.
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).
 
BR,
/Calin
 

From:
Chris Lauwers < lauwers@ubicity.com >
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define
attributes on topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop)
that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider
 a VNF described using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

 



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.  
 



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.  

 



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.
 

Hi Priya,
 
I must admit I don t really understand why existing substitution mapping mechanisms are not sufficient to accomplish your use case.
 
That said, there have been a number of interactions over email over the last couple of weeks that all seem to related to getting information from the substituting template back to a substituted node. Perhaps we can revisit your proposal
in the context of those discussions.
 
Thanks,
 
Chris
 
 


From: Priya T G <priya.g@netcracker.com>
Sent: Tuesday, November 20, 2018 5:53 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,
 
Apologies for the delay.  Regarding your response below,  the example is related to VNF instance name rather than VNF name and thus, it has to be an attribute.
For  retrieving a fully qualified custom name of a VDU,  the TOPOLOGY keyword helps to retrieve the VNF instance name associated with the VDU.
This is not related to notification as such, I was just attempting to demonstrate the need for TOPOLOGY keyword since you suggested another way ( snippet below )
for mapping the attributes in topology template to the abstract node template.
Did I clarify? Please let me know.
 
Regards,
Priya
 
We can still use this as it is for notifications:

We map the notification output still to the local node attribute Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, November 1, 2018 8:57 PM
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,
 
I don t know if I understand your example. Let me see:
 
If you cannot model the name of the VNF in the NS template as a property (since it will not be available at template parsing time), then it must be an attribute.

 
This also means that there has to be a way (operation, notification) that will give you this name as an output.
 
But since you have already substituted the node type with the substitution topology, you can receive this name directly in the substitution topology template via an operation or notification in the substitution template to which the original
operation or notification was mapped via substitution mappings.
 
Again, I don t know if I understood it well.
 
BR,
/Calin
 
 

From:
< tosca@lists.oasis-open.org > on behalf of Priya T G < priya.g@netcracker.com >
Date: Tuesday, 30 October 2018 at 14:36
To: Calin Curescu < calin.curescu@ericsson.com >, Chris Lauwers < lauwers@ubicity.com >
Cc: " tosca@lists.oasis-open.org " < tosca@lists.oasis-open.org >
Subject: RE: [tosca] Event Interface Proposal


 

Calin,
 
Apologies for the delay. Thank you for the clarification,  I agree that your proposal is an alternative for the TOPOLOGY keyword.
However, I would like to introduce an additional use case to demonstrate the need for this keyword. Sorry if this is a digression from the topic that is currently under discussion.

 
Consider a case of retrieving a fully qualified custom name for a node instance for e.g.
super_vnf1-vSRX .  It is not possible to feed this VNF name as topology input because all instances of the VNF will receive the same set of  input parameters.
If such a VNF node template in the NS descriptor has the VNF name as an attribute, then the TOPOLOGY keyword can help to retrieve this,  based on the VNF and VDU names as depicted below:
Let me know.
 
Regards,
Priya
 
 
 

 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, October 9, 2018 5:31 PM
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,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs) For the old-style operations, which had no outputs defined, this mapped fine Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

We map the notification output still to the local node attribute Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract node
operation/notification and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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


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.
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).
 
BR,
/Calin
 

From:
Chris Lauwers < lauwers@ubicity.com >
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define
attributes on topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop)
that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider
 a VNF described using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

 



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.  
 



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.  
 



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.  

Hi Chris,
 
Just to understand better, can you please clarify how the existing substitution mapping mechanism can help in the following case (in line with the email exchanges in the thread below):
 
PARENT TOPOLOGY:
SUBST_NODE:
 
CHILD TOPOLOGY:
 
topology_template:
SOME_NODE
 
I would like to have the following (i.e.
instance name of SUBST_NODE from parent topology + a node template name from child topology ):
SUBST_NODE-1@SOME_NODE-1
SUBST_NODE-1@SOME_NODE-2
SUBST_NODE-1@SOME_NODE-3
SUBST_NODE-2@SOME_NODE-1
SUBST_NODE-2@SOME_NODE-2
SUBST_NODE-2@SOME_NODE-3
 
Regards,
Priya
 


From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers
Sent: Monday, December 17, 2018 7:05 AM
To: Priya T G <priya.g@netcracker.com>; Calin Curescu <calin.curescu@ericsson.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya,
 
I must admit I don t really understand why existing substitution mapping mechanisms are not sufficient to accomplish your use case.
 
That said, there have been a number of interactions over email over the last couple of weeks that all seem to related to getting information from the substituting template back to a substituted node. Perhaps we can revisit your proposal
in the context of those discussions.
 
Thanks,
 
Chris
 
 


From: Priya T G < priya.g@netcracker.com >

Sent: Tuesday, November 20, 2018 5:53 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,
 
Apologies for the delay.  Regarding your response below,  the example is related to VNF instance name rather than VNF name and thus, it has to be an attribute.
For  retrieving a fully qualified custom name of a VDU,  the TOPOLOGY keyword helps to retrieve the VNF instance name associated with the VDU.
This is not related to notification as such, I was just attempting to demonstrate the need for TOPOLOGY keyword since you suggested another way ( snippet below )
for mapping the attributes in topology template to the abstract node template.
Did I clarify? Please let me know.
 
Regards,
Priya
 
We can still use this as it is for notifications:

-          
We map the notification output still to the local node attribute

-          
Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute

-          
The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, November 1, 2018 8:57 PM
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,
 
I don t know if I understand your example. Let me see:
 
If you cannot model the name of the VNF in the NS template as a property (since it will not be available at template parsing time), then it must be an attribute.

 
This also means that there has to be a way (operation, notification) that will give you this name as an output.
 
But since you have already substituted the node type with the substitution topology, you can receive this name directly in the substitution topology template via an operation or notification in the substitution template to which the original
operation or notification was mapped via substitution mappings.
 
Again, I don t know if I understood it well.
 
BR,
/Calin
 
 

From:
< tosca@lists.oasis-open.org > on behalf of Priya T G < priya.g@netcracker.com >
Date: Tuesday, 30 October 2018 at 14:36
To: Calin Curescu < calin.curescu@ericsson.com >, Chris Lauwers < lauwers@ubicity.com >
Cc: " tosca@lists.oasis-open.org " < tosca@lists.oasis-open.org >
Subject: RE: [tosca] Event Interface Proposal


 

Calin,
 
Apologies for the delay. Thank you for the clarification,  I agree that your proposal is an alternative for the TOPOLOGY keyword.
However, I would like to introduce an additional use case to demonstrate the need for this keyword. Sorry if this is a digression from the topic that is currently under discussion.

 
Consider a case of retrieving a fully qualified custom name for a node instance for e.g.
super_vnf1-vSRX .  It is not possible to feed this VNF name as topology input because all instances of the VNF will receive the same set of  input parameters.
If such a VNF node template in the NS descriptor has the VNF name as an attribute, then the TOPOLOGY keyword can help to retrieve this,  based on the VNF and VDU names as depicted below:
Let me know.
 
Regards,
Priya
 
 
 

 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, October 9, 2018 5:31 PM
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,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

-          
In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template

-          
Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs)

-          
For the old-style operations, which had no outputs defined, this mapped fine

-          
Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

-          
We map the notification output still to the local node attribute

-          
Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute

-          
The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract node
operation/notification and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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



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.




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).
 
BR,
/Calin
 

From:
Chris Lauwers < lauwers@ubicity.com >
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define
attributes on topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop)
that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider
 a VNF described using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

 



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.  
 



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.  
 



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.  


 



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.
 

Hi Priya,
 
When you say I would like to have the following where would you like to have those?
 
It sounds like those are names that are created in each of the nodes of the substituted template, in which case they should be modeled as attributes of those nodes (in the substituted template). I m not sure how this motivates the need
for attributes on a topology?
 
Thanks,
 
Chris
 


From: Priya T G <priya.g@netcracker.com>
Sent: Monday, December 17, 2018 7:26 AM
To: Chris Lauwers <lauwers@ubicity.com>; Calin Curescu <calin.curescu@ericsson.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
Hi Chris,
 
Just to understand better, can you please clarify how the existing substitution mapping mechanism can help in the following case (in line with the email exchanges in the thread below):
 
PARENT TOPOLOGY:
SUBST_NODE:
 
CHILD TOPOLOGY:
 
topology_template:
SOME_NODE
 
I would like to have the following (i.e.
instance name of SUBST_NODE from parent topology + a node template name from child topology ):
SUBST_NODE-1@SOME_NODE-1
SUBST_NODE-1@SOME_NODE-2
SUBST_NODE-1@SOME_NODE-3
SUBST_NODE-2@SOME_NODE-1
SUBST_NODE-2@SOME_NODE-2
SUBST_NODE-2@SOME_NODE-3
 
Regards,
Priya
 


From: tosca@lists.oasis-open.org [ mailto:tosca@lists.oasis-open.org ]
On Behalf Of Chris Lauwers
Sent: Monday, December 17, 2018 7:05 AM
To: Priya T G < priya.g@netcracker.com >; Calin Curescu < calin.curescu@ericsson.com >
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya,
 
I must admit I don t really understand why existing substitution mapping mechanisms are not sufficient to accomplish your use case.
 
That said, there have been a number of interactions over email over the last couple of weeks that all seem to related to getting information from the substituting template back to a substituted node. Perhaps we can revisit your proposal
in the context of those discussions.
 
Thanks,
 
Chris
 
 


From: Priya T G < priya.g@netcracker.com >

Sent: Tuesday, November 20, 2018 5:53 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,
 
Apologies for the delay.  Regarding your response below,  the example is related to VNF instance name rather than VNF name and thus, it has to be an attribute.
For  retrieving a fully qualified custom name of a VDU,  the TOPOLOGY keyword helps to retrieve the VNF instance name associated with the VDU.
This is not related to notification as such, I was just attempting to demonstrate the need for TOPOLOGY keyword since you suggested another way ( snippet below )
for mapping the attributes in topology template to the abstract node template.
Did I clarify? Please let me know.
 
Regards,
Priya
 
We can still use this as it is for notifications:

We map the notification output still to the local node attribute Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, November 1, 2018 8:57 PM
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,
 
I don t know if I understand your example. Let me see:
 
If you cannot model the name of the VNF in the NS template as a property (since it will not be available at template parsing time), then it must be an attribute.

 
This also means that there has to be a way (operation, notification) that will give you this name as an output.
 
But since you have already substituted the node type with the substitution topology, you can receive this name directly in the substitution topology template via an operation or notification in the substitution template to which the original
operation or notification was mapped via substitution mappings.
 
Again, I don t know if I understood it well.
 
BR,
/Calin
 
 

From:
< tosca@lists.oasis-open.org > on behalf of Priya T G < priya.g@netcracker.com >
Date: Tuesday, 30 October 2018 at 14:36
To: Calin Curescu < calin.curescu@ericsson.com >, Chris Lauwers < lauwers@ubicity.com >
Cc: " tosca@lists.oasis-open.org " < tosca@lists.oasis-open.org >
Subject: RE: [tosca] Event Interface Proposal


 

Calin,
 
Apologies for the delay. Thank you for the clarification,  I agree that your proposal is an alternative for the TOPOLOGY keyword.
However, I would like to introduce an additional use case to demonstrate the need for this keyword. Sorry if this is a digression from the topic that is currently under discussion.

 
Consider a case of retrieving a fully qualified custom name for a node instance for e.g.
super_vnf1-vSRX .  It is not possible to feed this VNF name as topology input because all instances of the VNF will receive the same set of  input parameters.
If such a VNF node template in the NS descriptor has the VNF name as an attribute, then the TOPOLOGY keyword can help to retrieve this,  based on the VNF and VDU names as depicted below:
Let me know.
 
Regards,
Priya
 
 
 

 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, October 9, 2018 5:31 PM
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,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs) For the old-style operations, which had no outputs defined, this mapped fine Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

We map the notification output still to the local node attribute Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract node
operation/notification and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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



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.




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).
 
BR,
/Calin
 

From:
Chris Lauwers < lauwers@ubicity.com >
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define
attributes on topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop)
that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider
 a VNF described using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

 



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.  
 



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.  
 



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.  

 



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.  

Hi Chris,
 
I would like to have the fully qualified names in the child template.
In the child template, the name of the nodes can be described as properties. However, the instance name (which is an attribute) of the abstract node in the parent template can be retrieved through get_attribute.
How can substitution mapping be used to get this attribute from parent topology to the child topology so that
the instance name from parent topology + node name of child topology can be appended to form a fully qualified name of the node in the child topology?
Please let me know.
 
Regards,
Priya
 


From: Chris Lauwers [mailto:lauwers@ubicity.com]
Sent: Monday, December 17, 2018 9:17 PM
To: Priya T G <priya.g@netcracker.com>; Calin Curescu <calin.curescu@ericsson.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya,
 
When you say I would like to have the following where would you like to have those?
 
It sounds like those are names that are created in each of the nodes of the substituted template, in which case they should be modeled as attributes of those nodes (in the substituted template). I m not sure how this motivates the need
for attributes on a topology?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Monday, December 17, 2018 7:26 AM
To: Chris Lauwers < lauwers@ubicity.com >; Calin Curescu < calin.curescu@ericsson.com >
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
Hi Chris,
 
Just to understand better, can you please clarify how the existing substitution mapping mechanism can help in the following case (in line with the email exchanges in the thread below):
 
PARENT TOPOLOGY:
SUBST_NODE:
 
CHILD TOPOLOGY:
 
topology_template:
SOME_NODE
 
I would like to have the following (i.e.
instance name of SUBST_NODE from parent topology + a node template name from child topology ):
SUBST_NODE-1@SOME_NODE-1
SUBST_NODE-1@SOME_NODE-2
SUBST_NODE-1@SOME_NODE-3
SUBST_NODE-2@SOME_NODE-1
SUBST_NODE-2@SOME_NODE-2
SUBST_NODE-2@SOME_NODE-3
 
Regards,
Priya
 


From: tosca@lists.oasis-open.org [ mailto:tosca@lists.oasis-open.org ]
On Behalf Of Chris Lauwers
Sent: Monday, December 17, 2018 7:05 AM
To: Priya T G < priya.g@netcracker.com >; Calin Curescu < calin.curescu@ericsson.com >
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya,
 
I must admit I don t really understand why existing substitution mapping mechanisms are not sufficient to accomplish your use case.
 
That said, there have been a number of interactions over email over the last couple of weeks that all seem to related to getting information from the substituting template back to a substituted node. Perhaps we can revisit your proposal
in the context of those discussions.
 
Thanks,
 
Chris
 
 


From: Priya T G < priya.g@netcracker.com >

Sent: Tuesday, November 20, 2018 5:53 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,
 
Apologies for the delay.  Regarding your response below,  the example is related to VNF instance name rather than VNF name and thus, it has to be an attribute.
For  retrieving a fully qualified custom name of a VDU,  the TOPOLOGY keyword helps to retrieve the VNF instance name associated with the VDU.
This is not related to notification as such, I was just attempting to demonstrate the need for TOPOLOGY keyword since you suggested another way ( snippet below )
for mapping the attributes in topology template to the abstract node template.
Did I clarify? Please let me know.
 
Regards,
Priya
 
We can still use this as it is for notifications:

-          
We map the notification output still to the local node attribute

-          
Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute

-          
The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, November 1, 2018 8:57 PM
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,
 
I don t know if I understand your example. Let me see:
 
If you cannot model the name of the VNF in the NS template as a property (since it will not be available at template parsing time), then it must be an attribute.

 
This also means that there has to be a way (operation, notification) that will give you this name as an output.
 
But since you have already substituted the node type with the substitution topology, you can receive this name directly in the substitution topology template via an operation or notification in the substitution template to which the original
operation or notification was mapped via substitution mappings.
 
Again, I don t know if I understood it well.
 
BR,
/Calin
 
 

From:
< tosca@lists.oasis-open.org > on behalf of Priya T G < priya.g@netcracker.com >
Date: Tuesday, 30 October 2018 at 14:36
To: Calin Curescu < calin.curescu@ericsson.com >, Chris Lauwers < lauwers@ubicity.com >
Cc: " tosca@lists.oasis-open.org " < tosca@lists.oasis-open.org >
Subject: RE: [tosca] Event Interface Proposal


 

Calin,
 
Apologies for the delay. Thank you for the clarification,  I agree that your proposal is an alternative for the TOPOLOGY keyword.
However, I would like to introduce an additional use case to demonstrate the need for this keyword. Sorry if this is a digression from the topic that is currently under discussion.

 
Consider a case of retrieving a fully qualified custom name for a node instance for e.g.
super_vnf1-vSRX .  It is not possible to feed this VNF name as topology input because all instances of the VNF will receive the same set of  input parameters.
If such a VNF node template in the NS descriptor has the VNF name as an attribute, then the TOPOLOGY keyword can help to retrieve this,  based on the VNF and VDU names as depicted below:
Let me know.
 
Regards,
Priya
 
 
 

 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, October 9, 2018 5:31 PM
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,
 
You raise a very important problem (I already tried to give some preliminary discussion in point 2. in my mail below - but did not manage to explain it well). I will try again:

-          
In a substitution mapping the operations of the abstract node are mapped to workflows of the substitution template

-          
Today workflows have no outputs (which is a miss in my opinion and not symmetric with inputs)

-          
For the old-style operations, which had no outputs defined, this mapped fine

-          
Any output (from the outputs section of the template) were mapped then back to the abstract nodes properties via substitutions mapping.
 
We can still use this as it is for notifications:

-          
We map the notification output still to the local node attribute

-          
Then we define an output of the substitution_template where we use get_attribute on that particular node s attribute

-          
The output will then be mapped (via rules in the substitution mapping) to attributes of the abstract node.
 
node_templates:
  node001:
    interfaces:
      avail_interface:  

        notifications:
          availability_report:
            outputs:
              name: availability
              value: [ SELF, monitor ]
       
outputs: #these are template-level outputs
  ubuntu_availability: { get_attribute: [node001, monitor] }
 
 
Now, as we recently added outputs to operations (and by extension to notifications), it would fit much better with the substitution if we would define outputs for workflows too, which would return them to the abstract node
operation/notification and be mapped by the rules defined there.
 
BR,
/Calin
 
 

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


 

Hi Calin,
 
Apologize for the delay , kindly refer to my response to Chris in another email thread for #2.
 
Regards,
Priya
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Thursday, October 04, 2018 7:45 PM
To: Priya T G; Chris Lauwers
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.
 
 
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



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.




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).
 
BR,
/Calin
 

From:
Chris Lauwers < lauwers@ubicity.com >
Date: Thursday, 4 October 2018 at 06:45
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


 

Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define
attributes on topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop)
that check some parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider
 a VNF described using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  

 



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.  
 



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.  
 



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.  

 



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.  


 



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.
 

Chris,
 
Apologies for causing confusion, as already indicated in one of my emails,  the TOPOLOGY key word is  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 (refer snippet below).
 
 
Regards,
Priya
 
 
  substitution_mappings:
      node_type: tosca.nodes.nfv.VNF.ubuntu
   
    capabilities:
     
      
    requirements:
      
 
          
  node_templates:
# VNF Components:
    ubuntu:
         type: tosca.nodes.nfv.VDU.Compute.ubuntu
      properties:
        name:
        description:
        
               ....
      interfaces:
       
      notifications:
        test_performance:
          availability:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitoring, ubuntu_availability ]
            implementation:                     #
               primary: alarm_processing          #  new 

              dependencies:                     #
                - test_artifact                        #

            events:
                      - tosca.events.attribute.changed
           
               
 
 
      
  policies:    
    - test:
         type: tosca.policies.test
        description:
        targets: [
TOPOLOGY ]
        triggers:
          - vnfc_trigger_1:
                       event: tosca.events..attribute.changed
              target_filter:
                node:
TOPOLOGY
              condition:
                constraint:
                  availability: [{ equal: not-available }]
             action:
 


From: Chris Lauwers [mailto:lauwers@ubicity.com]

Sent: Thursday, October 04, 2018 10:15 AM
To: Priya T G; Calin Curescu
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define attributes on
topologies?
 
Thanks,
 
Chris
 


From: Priya T G <priya.g@netcracker.com>
Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop) that check some
parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider  a VNF described
using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  



 



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.
 

Hi Priya,
 
The source of our confusion is the term topology attributes . TOSCA topologies do not have attributes. Only nodes and relationships do. What are you referring to when you say topology attributes ?
 
Thanks,
 
Chris
 
 


From: Priya T G <priya.g@netcracker.com>
Sent: Monday, October 08, 2018 9:19 AM
To: Chris Lauwers <lauwers@ubicity.com>; Calin Curescu <calin.curescu@ericsson.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
Chris,
 
Apologies for causing confusion, as already indicated in one of my emails,  the TOPOLOGY key word is  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 (refer snippet below).
 
 
Regards,
Priya
 
 
  substitution_mappings:
      node_type: tosca.nodes.nfv.VNF.ubuntu
   
    capabilities:
     
      
    requirements:
      
 
          
  node_templates:
# VNF Components:
    ubuntu:
         type: tosca.nodes.nfv.VDU.Compute.ubuntu
      properties:
        name:
        description:
        
               ....
      interfaces:
       
      notifications:
        test_performance:
          availability:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitoring, ubuntu_availability ]
            implementation:                     #
               primary: alarm_processing          #  new 

              dependencies:                     #
                - test_artifact                        #

            events:
                      - tosca.events.attribute.changed
           
               
 
 
      
  policies:    
    - test:
         type: tosca.policies.test
        description:
        targets: [
TOPOLOGY ]
        triggers:
          - vnfc_trigger_1:
                       event: tosca.events..attribute.changed
              target_filter:
                node:
TOPOLOGY
              condition:
                constraint:
                  availability: [{ equal: not-available }]
             action:
 


From: Chris Lauwers [ mailto:lauwers@ubicity.com ]

Sent: Thursday, October 04, 2018 10:15 AM
To: Priya T G; Calin Curescu
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define attributes on
topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop) that check some
parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider  a VNF described
using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  


 



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.  

Chris, Calin,
 
 
I am referring to the substitution mapping grammar ( refer below snippets)  when I refer to topology attributes . Of course, examples illustrating this are not present in the specifications.
Further questions, please let me know.
 
Regards,
Priya
 
 
                               

 
 
Refer the below snippet that further illustrates our proposal regarding use of TOPOLOGY keyword:
 
 

 
 
 
 
 


From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers
Sent: Monday, October 08, 2018 11:06 PM
To: Priya T G; Calin Curescu
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya,
 
The source of our confusion is the term topology attributes . TOSCA topologies do not have attributes. Only nodes and relationships do. What are you referring to when you say topology attributes ?
 
Thanks,
 
Chris
 
 


From: Priya T G <priya.g@netcracker.com>
Sent: Monday, October 08, 2018 9:19 AM
To: Chris Lauwers <lauwers@ubicity.com>; Calin Curescu <calin.curescu@ericsson.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
Chris,
 
Apologies for causing confusion, as already indicated in one of my emails,  the TOPOLOGY key word is  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 (refer snippet below).
 
 
Regards,
Priya
 
 
  substitution_mappings:
      node_type: tosca.nodes.nfv.VNF.ubuntu
   
    capabilities:
     
      
    requirements:
      
 
          
  node_templates:
# VNF Components:
    ubuntu:
         type: tosca.nodes.nfv.VDU.Compute.ubuntu
      properties:
        name:
        description:
        
               ....
      interfaces:
       
      notifications:
        test_performance:
          availability:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitoring, ubuntu_availability ]
            implementation:                     #
               primary: alarm_processing          #  new 

              dependencies:                     #
                - test_artifact                        #

            events:
                      - tosca.events.attribute.changed
           
               
 
 
      
  policies:    
    - test:
         type: tosca.policies.test
        description:
        targets: [
TOPOLOGY ]
        triggers:
          - vnfc_trigger_1:
                       event: tosca.events..attribute.changed
              target_filter:
                node:
TOPOLOGY
              condition:
                constraint:
                  availability: [{ equal: not-available }]
             action:
 


From: Chris Lauwers [ mailto:lauwers@ubicity.com ]

Sent: Thursday, October 04, 2018 10:15 AM
To: Priya T G; Calin Curescu
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Event Interface Proposal


 
[External Email]



 


Hi Priya, if there is a need to capture the availability of an entire VNF, wouldn t this require the definition of an availability attribute in the VNF node itself? If that s the case, why would there be a need to define attributes on
topologies?
 
Thanks,
 
Chris
 


From: Priya T G < priya.g@netcracker.com >

Sent: Wednesday, September 05, 2018 9:45 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,
 
Responses below:
 

For #1, of course , APIs are exposed to invoke notifications, However, I am referring to cases where the source of notification, for e.g,. bash scripts (with infinite loop) that check some
parameters on VM,   can be associated with the notification in the model.
 
   notifications :  #event_interfaces in the original proposal
        key_reports:
          availability_report:
            outputs:
              name: availability
              value: [
TOPOLOGY , monitor, ubuntu_availability ]
           
implementation:    #new                
              primary: alarm_processing         #  new

       
            event_types:
              - failure_monitoring
         fault_report:
            outputs:
              name: fault
              value: [ SELF, monitor, failure ]
           
implementation:                     #
              primary: alarm_processing         #  new

              dependencies:                     #
                - prober                         #

            event_types:
              - failure_processing             

 

The use of TOPOLOGY keyword is for reading attributes at the topology level. In your proposal, I see examples related to availability_monitoring or failure_monitoring. Consider  a VNF described
using a topology template.  While the availability of VDUs can be read through SELF keyword, it may be needed to check the availability of the entire VNF. In these cases, the TOPOLOGY keyword can be uaed on similar lines as SELF keyword.
 
Let me know your thoughts on this.
 
Regards,
Priya  
 
 


From: Calin Curescu [ mailto:calin.curescu@ericsson.com ]

Sent: Tuesday, September 04, 2018 6:47 PM
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:
 

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.
 

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:
 

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    

 

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.
 

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.  


 



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.  


 



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.