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:

capability_types:
  onap.capabilities.InfrastractureCompute:
    derived_from: tosca.capabilities.RootContainer
    description: a basic description of the infrastructurerequired hardware resources
    properties:
      architecture:
        description: vendor+architecture, for example, Intel64num_cpus:
        type: stringinteger
        required: false
         
      custom_features:
        description: |
     constraints:
    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: greater_or_equal: 1
      derivedcpu_fromfrequency:
onap.capabilities.Infrastracture     description: processor capabilities     properties:
      num_cpus:
        type: integerscalar-unit.frequency
        required: false
        constraints:
          - greater_or_equal: 0.1 GHz
      cpumem_frequencysize:
        type: scalar-unit.frequencysize
        required: false
        constraints:
          - greater_or_equal: 0.1 GHzMB
 

capability_types:   onap.capabilities.infrastructure.Memory:
    derived_from: onap.capabilities.Infrastracture
    description: memory capabilities
    properties:
      mem  storage_size:
        type: scalar-unit.size
        required: false
        constraints:
          - greater_or_equal: 0 MB

capability_types:   onap.capabilities.infrastructure.Storage:     derivedio_from: onap.capabilities.Infrastracturebitrate:
    description: storage specifications     propertiesdescription: bits      storage_size:per second
        type: scalar-unit.sizeinteger
        required: false
        constraintsarchitecture:
          - greater_or_equaldescription: 0 MB

capability_types:
  onap.capabilities.infrastructure.IO:
    derived_from: onap.capabilities.Infrastracture
    description: basic IO specificationsvendor+architecture, for example, Intel64
        type: string
        bitraterequired:  false       description: bits per second 
       typecustom_features:
integer         required: false

capability_types:     
  onap.capabilities.infrastructure.NIC:description: |
      derived_from: onap.capabilities.Infrastracture   Additional features description:, basicserialized IOin specificationsa    well-known format.
  bitrate:      type: string
 description: bits per second     required: false   type: integer      
 

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:

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:
      - cpuhost:
          capability: onap.capabilities.infrastructure.CPUCompute:
          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:
  - cpuhost:
      node_filter:
        capabilities: onap.capabilities.infrastructure.CPUCompute
        properties:
          num_cpus:
            - greater_or_equal: 2

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

# .. a node template, omitted...
requirements:
  - cpuhost:
      node_filter:
        capabilities: onap.capabilities.infrastructure.CPUCompute
        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_featurefeatures property is actually a JSON document.

...

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 Modified

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:

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