...

• tosca.capabilities.Container inherits from Compute!!!
• tosca.capabilities.Compute, property 'name' - we don't actually need it?
• tosca.capabilities.Storage is not similar to the tasca Compute - it only includes the 'name' property, does nor specify any storage quantifiers like size etc.
• in TOSCA Specs, Storage is not an infrastructure-level requirement; it is rather a kind of application-level (attachable, with an initial image), required by (attached to) other application nodes
• Tosca Compute capability is a mix of CPU+Mem. Don't we want to keep them apart for greater flexibility?
• TOSCA Specs does not have requirements for I/O
• TOSCA Specs normatives do not provide all information items required by the ETSI and IM
• tosca.capabilities.Compute and *.Storage bring with them unnecessary inheritance, coupling with relationship types, may affect the TOSCA declarative workflows

Proposed solution

1. Model the bassic basic HPA requirements with TOSCA capability types. VDUs will have requirements of these capability types. These HPA requirements will never be satisfied within the VNF and Service models, the orchestrator will do that in run-time
2. Abstain from using tosca.capability.Compute as it does not fully match the requirements
3. Define special ONAP capability types, separate for each of these categories: CPU, Memory, Storage, I/O, networking. These capability types express the most basic hardware characteristics. They also should be simple, flat bags of strictly named properties, all properties of primitive data types with clear restrictions.
4. Derive from the basic capability types an additional level of capabilities, with advanced (HPA) details. As detailed as they seem, these capabilities are still generic, with strict definitions of properties that are shared by the major hardware vendors. In addition to the strictly-typed properties, the HPA-level capabilities will also have a json-formatted property in order to allow for even greater customization flexibility.
5. Allow for further customization of the HPA-level capabilities into vendor-specific capabilities. These vendor-specific customized capabilities capability types may extend their HPA-level generic base by adding new properties and providing new constraints for the existing properties. In addition to the refinement of the strictly defined properties, the vendor-specific capabilities may provide their own validation schema for the json-formatted "flexible" property.

...

node_templates:
  vdu_123:
	type: onap.nodes.VDU
    capabilities:
      host:
    requirements:
      - memory:
          node_filter:
            capabilities:
              - onap.capabilities.infrastructure.Memory:
                  properties:
                    - mem_size: {greater_or_equal: 2MB}
      
      - cpu:
          node_filter:
            capabilities:
              - onap.capabilities.infrastructure.hpa.CPU:
                  properties:
                    - schema_selector:
                        constraints:  # fixed value for this vendor
                          - equal_to: Intel64 
                    - schema_version:
                        constraints:
                          - greater_or_equal: 2.0
                    - custom_features:
                        constraints:
                          - equals_to: {,,.sigjigigirgigmirig}
                          - schema: http://json.schema.url

Implications

• Compliance with TOSCA 1.2 for using JSON properties
• Support for the 'node_filter' construct
• New languages to understand: JSON Schema, XML Schema, etc