Taking advantage of TOSCA expressiveness
The ETSI information model is all defined in terms of information elements and their attributes. TOSCA proposes a much richer and more flexible meta-model; besides nodes and their properties, it offers to a designer such constructs as capabilities, requirements, relationships, policies, artifacts, interfaces, relationships, etc.
ETSI & ONAP Information Elements | TOSCA Constructs |
|---|---|
Descriptors: NSD, VNFD, PNFD | Topology Template to describe the internal composition and other implementation details; Node Type to express the “interface”; Node Template to represent an occurrence of the service/function within a higher-level composition (see Modelling Complex Resources) |
VLD, CpD | Normative Node Types and Node Templates based on these types (see Modelling Simple Resources) |
Information Elements | Data Types |
Naming, Scaling, Affinity | Policies |
Lifecycle, Operations | Interfaces |
Operation scripts, software images, etc. | Artifacts |
Properties vs. Metadata Fields
Property | Metadata Field |
|---|---|
Has to do with the core business purpose of the model object, what the model does. | Tells how the model object is maintained, stored, displayed, handled by business logic, etc. |
Examples: IP address, required amount of memory, virtualization container type | Examples: Author name, release number, change timestamp, ID in the data store |
Populated by vendor, designer | Populated by the infrastructure logic |
Inherited by derived types | - |
Used by functions (i.e. get_property()) | - |
Has a data type, including constraints to observe | No structure, just a loose string |
Design-time resource instances
Today ECOMP uses the term “instance” to designate a usage of a resource within a higher-level composition in design time. Should we introduce another term for such a design-time usage in order to prevent confusion with the run-time instances?
A resource occurrence maybe?
| Anchor | ||||
|---|---|---|---|---|
|
Modelling Simple Resources
A simple resource is a resource that cannot be decomposed into a topology of lower-layer component resources. Possible ways for a resource to be simple:
- The resource definition includes a complete set of artifacts which is sufficient for the orchestrator to create instances of this resource
- The resource is so basic and well-known that any orchestrator just knows what to do with it without any artifacts provided.
The following TOSCA constructs are used through this data model to represent simple resources:
- A TOSCA node type is used to model the simple resource definition.
- TOSCA node templates of this node type are used to represent occurrences (design-time instances) of this resource within a higher-level composition topology.
| Anchor | ||||
|---|---|---|---|---|
|
Modelling Complex Resources
A complex resource is a resource that is backed by a topology of lower-level component resources. The following TOSCA constructs are used through this data model to represent complex resources:
- A TOSCA topology template to describe the internal composition and other implementation details
- A TOSCA node type to express the “interface” capabilities, requirements, and properties of this resource
- A TOSCA substitution_mappings clause wires the capabilities, requirements and properties of this interface node type to the capabilities, requirements and properties of the component nodes inside the implementing topology template
- TOSCA node templates of the “interface” node type are used to represent occurrences of this complex resources within a higher-level composition