Page Comparison

All infrastructure capability types inherit from the basic The ONAP Data Model reflects the IM's ComputeDesc and MemoryDesc elements as the TOSCA capability type onap.capabilities.Compute.Infrastructure:

Code Block

title	Basic infrastructure capability type
linenumbers	true

capability_types:
  onap.capabilities.InfrastractureCompute:
    derived_from: tosca.capabilities.RootContainer
    description: a basic description of the required infrastructurehardware 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

Since all HPA-oriented capability types are derived from this basic type, they will all inherit its propertiesIn 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!

Based on this generic onap,capabilities.Infrastructure In spite the changes made in the capability type defininitions, the Data Model introduces a family of types that provide TOSCA support for the Informational Model elements.definition of the node type onap.nodes.Container does not change:

Code Block

title	onap.capabilitiesnodes.infrastructure.CPUContainer
linenumbers	true
collapse	true

capabilitynode_types:
  # the very base of the hierarchy of VDU types
  onap.capabilitiesnodes.infrastructure.CPUContainer:
    derived_from: onap.capabilitiesnodes.InfrastractureResource
    descriptionartifacts:
processor capabilities     propertiescontainer_image:
        num_cpustype: tosca.artifacts.Deployment
       type description: integeran image used to launch the Container
   required: false interfaces:
      Standard:
        constraintsstart:
          -implementation: greater_or_equal: 1container_image
    capabilities:
      host:
        cpu_frequencytype: tosca.capabilities.Container  # the TOSCA Specs type is good enough
        typeoccurrences: scalar-unit.frequency
[0..UNBOUNDED]
    requirements:
      - requiredhost:
 false         constraintscapability: onap.capabilities.Compute:
         - greater_or_equaloccurrences: [0..1 GHz

UNBOUNDED]

Examples of requirement assignments in their simplest form:

Code Block

title	onap.capabilities.infrastructure.MemoryRequirement for at least 2 vCPUs
linenumbers	true
collapse	true

capability_types:
  onap.capabilities.infrastructure.Memory:
    derived_from: onap.capabilities.Infrastracture
    description: memory capabilities
    properties# .. a node template, omitted...requirements:
  - host:
      memnode_sizefilter:
        typecapabilities: scalar-unit.sizeonap.capabilities.Compute
        requiredproperties:
 false         constraintsnum_cpus:
            - greater_or_equal: 0 MB
2

Examples of requirement assignments in the combined (TOSCA properties + custom_features) form:

Code Block

title	onap.capabilities.infrastructure.StorageRequirement for at least 2 vCPUs + bunch of Intel-specific features
linenumbers	true
collapse	true

capability_typesrequirements:
  onap.capabilities.infrastructure.Storage:
    derived_from: onap.capabilities.Infrastracture- host:
     description: storage specifications
    properties:
      storage_size node_filter:
        typecapabilities: scalar-unit.sizeonap.capabilities.Compute
        requiredproperties:
 false         constraintsnum_cpus:
            - greater_or_equal: 02
 MB

Code Block

title	onap.capabilities.infrastructure.IO
linenumbers	true
collapse	true

capability_types:   onap.capabilities.infrastructure.IO:     derivedcustom_fromfeatures: onap.capabilities.Infrastracture|
    description: basic IO specifications     {
 bitrate:         description: bits per second "simultaneousMultiThreading": true,
      type: integer       "simultaneousThreads": 10,
required: false

Code Block

title	onap.capabilities.infrastructure.NIC
linenumbers	true
collapse	true

capability_types:        onap.capabilities.infrastructure.NIC:     derived_from: onap.capabilities.Infrastracture"logicalCpuPinningPolicy": "Dedicated",
    description: basic IO specifications       bitrate"logicalCpuThreadPinningPolicy": "Prefer",
       description: bits per second    "instructionSetExtensions": ["aes", "sse", "ddio"],
 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:

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"directIoAccessToCache": "dca",
              "accelerator": "whatever you like",
       artifacts:       container_image:"measuredLaunchEnvironment": "",
        type: tosca.artifacts.Deployment     "secureEnclave": "",
  description: an image used to launch the Container     interfaces"hypervisorConfiguration": {
       Standard:         start"memoryCompaction": "best",
         implementation:  container_image     capabilities"kernelSamePageMerging": true
     host:         type: tosca.capabilities.Container},
  # the TOSCA Specs type is good enough     "computeRas": "pciDetectedAndCorrectedErrors"
  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:
 }

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:
        capabilitycapabilities: onap.capabilities.infrastructure.IOCPU
        properties:
          occurrences: [0..UNBOUNDED]num_cpus:
            - nic:greater_or_equal: 2
          capabilitycustom_features: onap.capabilities.infrastructure.NIC: 
            - occurrencesschema: [0..UNBOUNDED]http://my.domain.com/url/datatype.constraints.schema.json

Versions Compared

Old Version 6

New Version Current

Key