Thanks Paul, we started to discuss this challenge in depth in the ad-hoc meeting.
In my view, you're on the right track. For specific systems that need to identify node instances we can use attributes. That allows the values to be filled by an external system, whether it's the platform itself or an orchestrator that manages IDs. TOSCA would then let you model the data type for that identifying attribute as is appropriate.
The problem is that we still don't entirely understand what attributes are in TOSCA. :) Even more specifically we don't have tools for using attributes as unique identifiers.
Here's one possible approach:
We add a keyword called "unique" (boolean) to attribute declarations. When "unique: true" is set on an attribute it is a signal to orchestrators that multiple instances (whatever that would mean in any specific implementation) would require unique identification management for this attribute. How this is done would be out of scope for TOSCA, and indeed in many cases would be handled by the platform itself, e.g. you spin up a virtual machine and get a GUID after it's created. Is it not a GUID, but rather an ID that is unique only per cluster? Then maybe your attribute needs to comprise a combination of cluster ID and resource ID in order to be unique. You can model that easily in TOSCA. Note that it might also be possible to have multiple attributes marked as unique. Why not? There might be different unique IDs coming from different parts of the system but all refer to the same "node" as you've encapsulated it in TOSCA.
So why have the keyword at all? Well, now that we know this attribute is unique we can use it as a grammatical reference in functions, specifically the get_attribute function (but also get_artifact and possibly others). Right now get_attribute uses either a node template name or magic keyword (SELF, SOURCE, TARGET) as the "modelable entity name", but I think we would all agree that this is poorly defined. A unique ID attribute can help us narrow what we mean. In trying to brainstorm, here's something I came up with:
A new intrinsic function called "select". This implementation-specific function can search through the runtime or orchestration universes and return a list of IDs. This result (the list of IDs) can then be used as the "modelable entity name" for get_attribute. An example:
data_types:
 ID:
ÂÂÂ properties:
ÂÂÂÂÂ cluster_name:
ÂÂÂÂÂÂÂ type: string
ÂÂÂÂÂ serial_number:
ÂÂÂÂÂÂÂ type: integer
node_types:
 Server:
ÂÂÂ attributes:
   identifier:
ÂÂÂÂÂÂÂ type: ID
ÂÂÂÂÂÂÂ unique: true
ÂÂÂÂÂ current_ram:
ÂÂÂÂÂÂÂ type: scalar-unit.size
topology_template:
 inputs:
ÂÂÂ os:
ÂÂÂÂÂ type: string
ÂÂÂÂÂ default: linux
 node_templates:
ÂÂÂ server:
ÂÂÂÂÂ type: Server
ÂÂ outputs:
ÂÂÂÂÂ total_ram_use: { get_attribute: [ { select: [ server, identifier, "where os = ", { get_input: os } ] }, current_ram }
The "select" function here has the following arguments: first argument is template name (or SELF, SOURCE, TARGET) and the second is the name of an attribute that must be marked as "unique: true". The rest of the arguments will remain as implementation specific. In this example I'm assuming an orchestrator that has some kind of textual querying language. The get_attribute function then uses the result of this function as its first argument, which would be zero or more instance IDs of that specific node template. For those instances it would extract the "current_ram" attribute. What would the result be? I think it should be a dict of ID mapped to attribute value. So that output can then be used by other parts of orchestration to calculate averages, create a total sum, etc.
And those IDs are also consistent. So if, for example, you have multiple outputs with different "select" queries and different attributes, well, that's fine, somewhere down the toolchain you are guaranteed that they refer to the same instance of that node template, so you can cross-reference and construct whatever totals or graphs you want from those outputs.
I see in the TOSCA TC mailing list a discussion about multiplicity. Good that has been a an area of confusion for me.
In particular an email from Peter Bruun about node identities.
Iâd just like to mention that in my work on mapping TMForum to TOSCA I have a profile where every one of my node types is derived from a root type which represents the SID RootEntity. The SID RootEntity is defined as having a mandatory
Name and ID plus an optional description thus.
Â
|
ID
|
RootEntity
|
required
|
Unambiguously distinguishes different object instances.
|
|
description
|
RootEntity
|
Â
|
This is a string, and defines a textual free-form description of the object. Notes: This attribute doesnât exist in M.3100. The CIM has
two attributes for this purpose, Caption (a short description) and Description.
|
|
name
|
RootEntity
|
required
|
Represents a user-friendly identifier of an object. It is a (possibly ambiguous) name by which the object is commonly known in some limited
scope (such as an organization) and conforms to the naming conventions of the country or culture with which it is associated. It is NOT used as a naming attribute (i.e., to uniquely identify an instance of the object).
|
Â
Â
Paul Jordan
OSS Specialist
BT Technology |
Tel
+44 (0) 3316252643
Â|
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
Â