[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Event Interface Proposal
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> 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 [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>
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:
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]
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> 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]
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:
We can still use this as it is for notifications:
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> 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]
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:
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> 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>
Calin, Responses below:
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
Let me know your thoughts on this. Regards, Priya From: Calin Curescu [mailto:calin.curescu@ericsson.com]
Chris: Sure. However the reader should be aware of the important difference here:
Then I would lobby to introduce in the interface definition the keyword âoperationsâ to gather the operations symbolic name and the keyword ânotificationsâ to gather the notifications symbolic names. Anyway the former is already required since not having it clashes with the âinputsâ section of the interfaces (see matt comment in section 3.7.5.2. Grammar of Interface Type Definitions). Priya: please fins some inline comments in your text below. Btw, I think the ânotificationâ name fits very well, so I will use that from now on. BR, /Calin From:
Chris Lauwers <lauwers@ubicity.com> I like these concepts, but Iâd like to avoid having to create new âinterface typesâ just for events or notifications. We already have too many types of types. Canât we just add a notifications or events keyname to the existing interface definitions? Chris From: Priya T G <priya.g@netcracker.com>
Calin, Thanks for responding. Clarifications below:
What I mean is that anybody can invoke the notifications, the association with the artifact is not useful since we are just exposing an API here.
a.
Attribute - by means of get_operation_ouput function in attribute definition/assignment b.
Operation â by means of output section Topology attributes can be filled through substitution mapping. We could adhere to a common approach and provide possibility to fill topology attributes through operation (or event) and read topology
attribute values from node instances inside topology. In the case of substitution mapping, the properties of the substituted node are mapped to the inputs of the substitution topology template, and the outputs of the topology template
are mapped back to the attributes of the substituted node. So we could use the outputs here, where they could get assigned using get_attribute from a specific node. Then we do not need the TOPOLOGY keyword (and anyway there are no
global attributes section of a topology template. Let me know your views. Regards, Priya From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Calin Curescu Hi Priya, I realized I have not answered to your mail, I was hoping to discuss it all in the WG meeting before we go further. Anyway, some first thoughts on your proposals inline. BR, /Calin From:
<tosca@lists.oasis-open.org> on behalf of Priya T G <priya.g@netcracker.com> Hello Calin, Chris, This is regarding the event interface proposal that was uploaded in OASIS portal recently: https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/63289/EventInterface2018_06_20.docx
I believe this has not yet been discussed in TOSCA Simple Profile meetings, but is in plan for TOSCA YAML v1.3. I have a few comments and suggestions on this:
I was thinking initially that the orchestrator will provide a couple of standard interface technologies (HTTP/REST, RPC, â) to accept these notifications, where the data model exchanged is YAML/JSON.
So an external implementation would know exactly how to format data and use the API.
The only effect in the orchestrator is that attributes values are updated and specific orchestrator events are generated. The events may then trigger workflows are already defined in TOSCA, and these
workflows can then call operations that artifact implementations can be attached to. If we want to have a shortcut for the latter step (i.e. not needing to set up and specify an entire workflow), Iâm more inclined that we provide an extra âcall_operationâ
keyword in the definition that will call a specific operation i.e: fault_report: outputs: name: fault value: [ SELF, monitor, failure ] event_types: - failure_processing call_operation: #new - SELF.alarm_processing #new
Notification is a good alternative. Letâs propose it to the group.
I donât think I understand the TOPOLOGY reference. Afaik, there are no attributes that are connected to the topology_template. BR, /Calin The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or
privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]