The ONAP Data Model implements the IM's ComputeDesc and MemoryDesc elements as TOSCA capabilities of the type onap.capabilities.Compute.

This capability characterizes a virtual machine. Intended to be used primarily as part of a TOSCA requirement clause. Normally, requirements of this type are never satisfied within the model. They stay “dangling” until instantiation. On instantiation, the orchestrator satisfies them out of the available inventory.

 Definition

capability_types:
  onap.capabilities.Compute:
    description: |
      When used with a requirement, describes infrastructure-level 
      computational power consumed by the node
    derived_from: tosca.capabilities.Container
    properties:
      num_cpus:
        description: number of virtual CPUs
        type: integer
        constraints:
          - greater_or_equal: 1
        required: false     
      cpu_frequency:
        description: CPU clock rate
        type: scalar-unit.frequency
        constraints:
          - greater_or_equal: 0.1 GHz
      mem_size:
        description: amount of memory
        type: scalar-unit.size
        required: false
        constraints:
          - greater_or_equal: 0 MB
      storage_size:
        description: amount of internal disk storage
        type: scalar-unit.size
        required: false
        constraints:
          - greater_or_equal: 0 MB
      io_bitrate:
        description: IO performance, in 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: onap.datatypes.json
        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. It is of the onap.datatypes.json data type, meaning that it is a JSON-formatted string. Can be treated as just a plain string. 


Examples of requirement assignments in their simplest form:

Requirement for at least 2 vCPUs 
# .. 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:

Requirement for at least 2 vCPUs + bunch of Intel-specific features 
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:

Example of JSON Schema for CPU custom features 
{
  "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. 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:

External JSON schema in a TOSCA requirement assignment 
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



  • No labels