Calin,
Referring to node_extension_v2.yaml, in my mind the common file (or profile) would contain everything up to line 57. In reality this section would be a large number of node and relationship types in that file representing a complex graph. The node types would include parameter definitions, attribute definitions and interfaces containing notifications, all of which would use well-known names because they are derived from TMForum definitions. As I think you understand, this could be done using todays syntax but would be inefficient because of the need to create a capability for each relationship name. – It is that inefficiency that I’m striving to achieve.
The template author would create hosted_app_type. Rather than inventing data structures for its parameters, or coping and pasting for TMF documents, the author would extend the node type using just a small number of extension nodes. In doing so the node would inherit the complex graph of extension nodes with their well known names.
Parameters in interfaces on the deployable nodes could be mapped to the inherited parameters in the extension nodes. Policy and workflow would reference the parameters in the extension nodes.
The attachments show a UML example of a complex topology derived from TMForum SID and how this might be placed in a TOSCA topology using the node extension pattern.
I will be discussing this use case in a TMForum meeting on Dec 8th. Since Ericsson is a TMForum member you have the right to attend.
Paul Jordan
OSS Specialist
BT Technology<https: intra.bt.com/bt/tso=""> | Tel +44 (0) 3316252643 |
paul.m.jordan@bt.com<mailto:
paul.m.jordan@bt.com>
This email contains information from BT that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.
We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000
From: Calin Curescu <
calin.curescu@ericsson.com>
Sent: 03 December 2020 11:49
To: Jordan,PM,Paul,TNK6 R <
paul.m.jordan@bt.com>;
lauwers@ubicity.com;
tosca-comment@lists.oasis-open.orgSubject: Re: [tosca-comment] RE: Restricting relationship types to node types and node types with capability types.
Hi Paul,
It seems that if you want to specify the relationship between two nodes in the common file (or profile) then you need to define a requirement in the source node type, where you specify the relationship to be used. Now, within the same requirement definition you can alternatively use the node keyname. So, it would seem that being able to specify the valid_target_node_types in the relationship type will not allow for a higher granularity level specification e.g:
DeployableNode:
…
requirements:
- extension:
capability: NodeExtension
relationship: NodeIsExtendedBy
node: ExtensionNode
But maybe I don’t have a good image of your use-case; could you send a short example of your intended usage?
Regarding the error hiding I mention in the second paragraph, it would only appear if the the node type restriction would be expressed in the relationship type definition as you requested. Today such situation does not exist since the capability specification in the requirement in the node type is mandatory, thus the valid_target_types constraint in the relationship cannot act like a hidden constraint.
Thanks for your relevant questions,
BR/C
From: < /><mailto:
tosca-comment@lists.oasis-open.org>> on behalf of "
paul.m.jordan@bt.com<mailto:
paul.m.jordan@bt.com>" < /><mailto:
paul.m.jordan@bt.com>>
Date: Thursday, 3 December 2020 at 12:14
To: Calin Curescu < /><mailto:
calin.curescu@ericsson.com>>, "
lauwers@ubicity.com<mailto:
lauwers@ubicity.com>" < /><mailto:
lauwers@ubicity.com>>, "
tosca-comment@lists.oasis-open.org<mailto:
tosca-comment@lists.oasis-open.org>" < /><mailto:
tosca-comment@lists.oasis-open.org>>
Subject: RE: [tosca-comment] RE: Restricting relationship types to node types and node types with capability types.
Calin,
Thanks for joining the conversation.
I hadn’t previously considered making use of the node keyword. While it does appear to apply the restriction I’m looking for it occurs in the syntax at an inconvenient point.
My aim is to predefine the extension nodes and their relationships in file (or profile) which is created once from the TMForum SID using tooling. That common file would then be available to template authors to who wish to extend their deployable nodes with the standard MetricABE structure. The node keyword for MetricDefinition occurs within the hosted_app_type type definition and so could not be part of that common file.
Would the orchestrator error reporting problem that you mention in your second paragraph be eased if the node type restriction could be expressed in the relationship type definition as I requested?
Paul Jordan
OSS Specialist
BT Technology<https: eur02.safelinks.protection.outlook.com/?url="https%3A%2F%2Fintra.bt.com%2Fbt%2Ftso&data=04%7C01%7Cpaul.m.jordan%40bt.com%7Ce86fa7fcc4a146bac7a408d897816bad%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C1%7C637425929628368766%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bQWjoqac2FGLnuKo22uuAX7%2F%2Bj6iRMsXmYXSPWjgdIo%3D&reserved=0"> | Tel +44 (0) 3316252643 |
paul.m.jordan@bt.com<mailto:
paul.m.jordan@bt.com>
This email contains information from BT that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.
We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000
From: Calin Curescu < /><mailto:
calin.curescu@ericsson.com>>
Sent: 02 December 2020 23:11
To: Jordan,PM,Paul,TNK6 R < /><mailto:
paul.m.jordan@bt.com>>;
lauwers@ubicity.com<mailto:
lauwers@ubicity.com>;
tosca-comment@lists.oasis-open.org<mailto:
tosca-comment@lists.oasis-open.org>
Subject: Re: [tosca-comment] RE: Restricting relationship types to node types and node types with capability types.
Hi Paul,
If you don’t need the different capability types, then I think you can just use one capability type and use the requirement definition where you can either restrict the capability type (via the capability keyword) or restrict the node type (via the node keyword). Please see the attached yaml.
One observation that I made is that the valid_target_types (as it is now) acts only like a constraint on the capability type you need to choose in the requirement definition (i.e. the orchestrator will not validate the template if mismatched). On the other hand the node keyname is not mandatory in the requirement definition. Thus, in the case the target node type is not defined in the requirement, the valid_target_node_types would act as a node_filter that is not defined in the requirement but in the relationship type (i.e. the orchestrator will not return a validation error, but will need to filter out such invalid node types at runtime). Thus errors w.r.t. the latter will be harder to discover.
BR,
/Calin
From: < /><mailto:
tosca-comment@lists.oasis-open.org>> on behalf of "
paul.m.jordan@bt.com<mailto:
paul.m.jordan@bt.com>" < /><mailto:
paul.m.jordan@bt.com>>
Date: Tuesday, 1 December 2020 at 11:57
To: "
lauwers@ubicity.com<mailto:
lauwers@ubicity.com>" < /><mailto:
lauwers@ubicity.com>>, "
tosca-comment@lists.oasis-open.org<mailto:
tosca-comment@lists.oasis-open.org>" < /><mailto:
tosca-comment@lists.oasis-open.org>>
Subject: [tosca-comment] RE: Restricting relationship types to node types and node types with capability types.
Chris,
Thanks for taking the time on this. There is nothing wrong with what you have done here. My problem occurred when expanding this pattern to larder numbers of extension nodes:
There will be many node_types derived_from MetricABE in the same way as you have done for MetricDefinition.
Many pairs of these derived node types will have a relationship between them and that relationship has its own name.
In order to create all those relationships with different names, there will many relationship_types derived_from NodeIsExtendedBy in the same way as you have done for MetricDefinitionMeasures.
I will need to restrict the use of each of these relationship types to the specific pair of node_types which use that name.
You have achieved that using the MetricDefinitionExtention capability type. My point is that all these capabilities would be defined only for this job which adds about 30% more lines to the template. I could avoid all that if a revised syntax allowed me to restrict the application of the relationships by referencing the node_type rather than referencing a capability_type within the node type.
Regards
Paul Jordan
OSS Specialist
BT Technology<https: eur02.safelinks.protection.outlook.com/?url="https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dc2b1192f-9d2a236a-c2b159b4-867b36d1634c-2d254e3513bb7ed1%26q%3D1%26e%3D26f3af51-048d-496f-9a59-dde28b62c538%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fintra.bt.com%25252Fbt%25252Ftso%2526data%253D04%25257C01%25257Cpaul.m.jordan%252540bt.com%25257C3dcd105b1c1c46dde97208d897178d76%25257Ca7f356889c004d5eba4129f146377ab0%25257C0%25257C1%25257C637425475166198937%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C1000%2526sdata%253Dabd%25252FoL%25252FXeFmxHqmLcfT1QDcnTn2tMQ5De0aVSAHsufI%25253D%2526reserved%253D0&data=04%7C01%7Cpaul.m.jordan%40bt.com%7Ce86fa7fcc4a146bac7a408d897816bad%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637425929628368766%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1oDhoLwqkgVEUOU08zmAvSCQSF8PiA4VkASSPFMXsJY%3D&reserved=0"> | Tel +44 (0) 3316252643 |
paul.m.jordan@bt.com<mailto:
paul.m.jordan@bt.com>
This email contains information from BT that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.
We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000
From: Chris Lauwers < /><mailto:
lauwers@ubicity.com>>
Sent: 30 November 2020 19:59
To: Jordan,PM,Paul,TNK6 R < /><mailto:
paul.m.jordan@bt.com>>;
tosca-comment@lists.oasis-open.org<mailto:
tosca-comment@lists.oasis-open.org>
Subject: RE: Restricting relationship types to node types and node types with capability types.
Hi Paul,
I’m attaching a very rudimentary TOSCA template that starts to implement your pattern for the SID Metric ABE. It shows how relationship types can be refined by limiting valid_target_types to derived types of the NodeExtension capability type.
I’d love to work with you to flesh this out further if you’re interested.
Thanks,
Chris
From: Chris Lauwers
Sent: Sunday, November 29, 2020 6:15 PM
To:
paul.m.jordan@bt.com<mailto:
paul.m.jordan@bt.com>;
tosca-comment@lists.oasis-open.org<mailto:
tosca-comment@lists.oasis-open.org>
Subject: RE: Restricting relationship types to node types and node types with capability types.
Thanks Paul, we’ll take this up for review. In the meantime, a couple of additional comments:
* If we were to rename the “valid_target_types” keyword, then perhaps “valid_target_capability_types” may be the more accurate description.
* As we discussed, I believe your pattern can be supported by subclassing capability types. You mentioned that might be too cumbersome, but I’ll try to work through your example to get a feel for how bad it really is
</mailto:
tosca-comment@lists.oasis-open.org></mailto:
paul.m.jordan@bt.com></mailto:
tosca-comment@lists.oasis-open.org></mailto:
paul.m.jordan@bt.com></mailto:
lauwers@ubicity.com></mailto:
paul.m.jordan@bt.com></https:></mailto:
tosca-comment@lists.oasis-open.org></mailto:
tosca-comment@lists.oasis-open.org></mailto:
lauwers@ubicity.com></mailto:
lauwers@ubicity.com></mailto:
paul.m.jordan@bt.com></mailto:
paul.m.jordan@bt.com></mailto:
tosca-comment@lists.oasis-open.org></mailto:
tosca-comment@lists.oasis-open.org></mailto:
lauwers@ubicity.com></mailto:
paul.m.jordan@bt.com></mailto:
calin.curescu@ericsson.com></mailto:
paul.m.jordan@bt.com></https:></mailto:
tosca-comment@lists.oasis-open.org></mailto:
tosca-comment@lists.oasis-open.org></mailto:
lauwers@ubicity.com></mailto:
lauwers@ubicity.com></mailto:
calin.curescu@ericsson.com></mailto:
paul.m.jordan@bt.com></mailto:
paul.m.jordan@bt.com></mailto:
tosca-comment@lists.oasis-open.org></
paul.m.jordan@bt.com></
calin.curescu@ericsson.com></mailto:
paul.m.jordan@bt.com></https:>