All infrastructure capability types inherit from the basic onap.capabilities.Infrastructure:
capability_types:
onap.capabilities.Infrastracture:
derived_from: tosca.capabilities.Root
description: a basic description of infrastructure resources
properties:
architecture:
description: vendor+architecture, for example, Intel64
type: string
required: false
custom_features:
description: |
Additional features description, serialized in a well-known format.
type: string
required: false
Since all HPA-oriented capability types are derived from this basic type, they will all inherit its properties:
- architecture - allows the VFC vendors to focus their requirements on a specific hardware architecture, for example "Intel x86".
- custom_features - an opaque container for a list of feature definitions. Any text, the only limitation is that it should not break the YAML/TOSCA formatting. The contents of this property is actually not part of the TOSCA model!
Based on this generic onap,capabilities.Infrastructure capability type, the Data Model introduces a family of types that provide TOSCA support for the Informational Model elements.
capability_types:
onap.capabilities.infrastructure.CPU:
derived_from: onap.capabilities.Infrastracture
description: processor capabilities
properties:
num_cpus:
type: integer
required: false
constraints:
- greater_or_equal: 1
cpu_frequency:
type: scalar-unit.frequency
required: false
constraints:
- greater_or_equal: 0.1 GHz
capability_types:
onap.capabilities.infrastructure.Memory:
derived_from: onap.capabilities.Infrastracture
description: memory capabilities
properties:
mem_size:
type: scalar-unit.size
required: false
constraints:
- greater_or_equal: 0 MB
capability_types:
onap.capabilities.infrastructure.Storage:
derived_from: onap.capabilities.Infrastracture
description: storage specifications
properties:
storage_size:
type: scalar-unit.size
required: false
constraints:
- greater_or_equal: 0 MB
capability_types:
onap.capabilities.infrastructure.IO:
derived_from: onap.capabilities.Infrastracture
description: basic IO specifications
bitrate:
description: bits per second
type: integer
required: false
capability_types:
onap.capabilities.infrastructure.NIC:
derived_from: onap.capabilities.Infrastracture
description: basic IO specifications
bitrate:
description: bits per second
type: integer
required: false
In spite the changes made in the capability type defininitions, the definition of the node type onap.nodes.Container does not change:
node_types:
# the very base of the hierarchy of VDU types
onap.nodes.Container:
derived_from: onap.nodes.Resource
artifacts:
container_image:
type: tosca.artifacts.Deployment
description: an image used to launch the Container
interfaces:
Standard:
start:
implementation: container_image
capabilities:
host:
type: tosca.capabilities.Container # the TOSCA Specs type is good enough
occurrences: [0..UNBOUNDED]
requirements:
- cpu:
capability: onap.capabilities.infrastructure.CPU:
occurrences: [0..1]
- memory:
capability: onap.capabilities.infrastructure.Memory:
occurrences: [0..UNBOUNDED]
- storage:
capability: onap.capabilities.infrastructure.Storage:
occurrences: [0..UNBOUNDED]
- io:
capability: onap.capabilities.infrastructure.IO:
occurrences: [0..UNBOUNDED]
- nic:
capability: onap.capabilities.infrastructure.NIC:
occurrences: [0..UNBOUNDED]
Examples of requirement assignments in their simplest form:
# .. a node template, omitted...
requirements:
- cpu:
node_filter:
capabilities: onap.capabilities.infrastructure.CPU
properties:
num_cpus:
- greater_or_equal: 2
Examples of requirement assignments in the combined (TOSCA properties + custom_features) form:
# .. a node template, omitted...
requirements:
- cpu:
node_filter:
capabilities: onap.capabilities.infrastructure.CPU
properties:
num_cpus:
- greater_or_equal: 2
architecture:
- equal: IntelXYZ
custom_features: |
{
"simultaneousMultiThreading": true,
"simultaneousThreads": 10,
"logicalCpuPinningPolicy": "Dedicated",
"logicalCpuThreadPinningPolicy": "Prefer",
"instructionSetExtensions": ["aes", "sse", "ddio"],
"directIoAccessToCache": "dca",
"accelerator": "whatever you like",
"measuredLaunchEnvironment": "",
"secureEnclave": "",
"hypervisorConfiguration": {
"memoryCompaction": "best",
"kernelSamePageMerging": true
},
"computeRas": "pciDetectedAndCorrectedErrors"
}
In the example above the text in the custom_feature property is actually a JSON document.
The hardware vendors are encouraged to provide a well-defined schema (JSON Schema for JSON-formatted texts, DTD or XML Schema for XML-formatted texts, etc) to govern syntax of their custom_feature texts. For example, a JSON schema for the CPU custom feature fron the example above may look like this:
{
"definitions": {
"hypervisorConfiguration": {
"type": "object",
"properties": {
"memoryCompaction": { "enum": [ "best", "worst", "optimal" ] },
"kernelSamePageMerging": {"type": "boolean" }
}
}
},
"type": "object",
"properties": {
"simultaneousMultiThreading": {"type": "boolean"},
"simultaneousThreads": {"type": "integer", "minimum": 1, "maximum": 4},
"logicalCpuPinningPolicy": {"type": "string" },
"hypervisorConfiguration": { "$ref": "#/definitions/hypervisorConfiguration" },
"instructionSetExtensions": {
"type": "array",
"items": {
"type": "string",
"enum": [ "aes", "sse", "avx", "cat", "cmt", "mbm", "ddio", "smt", "rdrand" ]
}
}
}
}
The idea of using a schema document together with the custom_features text seems to be very powerful. For a demostration of how such a schema would work, please visit any of the JSON schema validators available online, for example, https://json-schema-validator.herokuapp.com/. Just copy and paste over there the above JSON schema and the value of the custom_feature field and check on the validation results:
TOSCA 1.2 allows using a JSON schema as a TOSCA constraint in parameter definition and node_filter clauses.