The ONAP Data Model reflects the IM's ComputeDesc and MemoryDesc elements as the TOSCA capability type onap.capabilities.Compute.
| Code Block |
|---|
| title | Basic infrastructure capability type |
|---|
| linenumbers | true |
|---|
|
capability_types:
onap.capabilities.Compute:
derived_from: tosca.capabilities.Container
description: a description of the required hardware resources
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
mem_size:
type: scalar-unit.size
required: false
constraints:
- greater_or_equal: 0 MB
storage_size:
type: scalar-unit.size
required: false
constraints:
- greater_or_equal: 0 MB
io_bitrate:
description: bits per second
type: integer
required: false
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
|
In addtition to the obvious properties required by the IM, this capability type also includes properties that allow for easy customization:
- 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!
In spite the changes made in the capability type defininitions, the definition of the node type onap.nodes.Container does not change:
| Code Block |
|---|
| title | onap.nodes.Container |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
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:
- host:
capability: onap.capabilities.Compute:
occurrences: [0..UNBOUNDED]
|
Examples of requirement assignments in their simplest form:
| Code Block |
|---|
| title | Requirement for at least 2 vCPUs |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
# .. a node template, omitted...requirements:
- host:
node_filter:
capabilities: onap.capabilities.Compute
properties:
num_cpus:
- greater_or_equal: 2
|
Examples of requirement assignments in the combined (TOSCA properties + custom_features) form:
| Code Block |
|---|
| title | Requirement for at least 2 vCPUs + bunch of Intel-specific features |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
requirements:
- host:
node_filter:
capabilities: onap.capabilities.Compute
properties:
num_cpus:
- greater_or_equal: 2
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_features 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:
| Code Block |
|---|
| language | js |
|---|
| title | Example of JSON Schema for CPU custom features |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
{
"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:
Image Added
TOSCA 1.2 allows using a JSON schema as a TOSCA constraint in parameter definition and node_filter clauses. Using an external schema document (with a Web URL in the TOSCA constraint clause) seems to be especially promising, since such usage combines the benefits of schema-driven validation with the flexibility of having the schema hosted outside:
| Code Block |
|---|
| title | External JSON schema in a TOSCA requirement assignment |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
requirements:
- host:
node_filter:
capabilities: onap.capabilities.infrastructure.CPU
properties:
num_cpus:
- greater_or_equal: 2
custom_features:
- schema: http://my.domain.com/url/datatype.constraints.schema.json |