Splitting VDU: VFC + Container

Owned by Anatoly Katzman
Last updated: Feb 25, 2018
5 min read

onap.nodes.ComputeIn the Info Model, the VDU element combines 2 aspects: application logic and expectations of the underlying infrastructure.

The Data Model implements the IM VDU element as a pair of related resources:

  1. VFC - an ONAP resource that represents a piece of application-level logic and includes:

    1. a requirement for hosting by a container

    2. a software image to launch the application logic on the container

    3. a free set of application-level requirements and capabilities

  2. Container - an ONAP resource that represents a unit of infrastructure allocation. It expresses the following ideas:

    1. a "hardware shopping list" - in the terms of TOSCA requirements, which are based on specially designed TOSCA capability types

    2. a software image that the Orchestrator uses to launch such a unit - by means of a TOSCA artifact 

    3. an ability to host application logic - modeled as a TOSCA capability of a special capability type







ONAP Data Model Normatives
node_types: # the very base of the hierarchy of VDU types onap.nodes.Compute: 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: - 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: capability: onap.capabilities.infrastructure.IO: occurrences: [0..UNBOUNDED] - nic: capability: onap.capabilities.infrastructure.NIC: occurrences: [0..UNBOUNDED]

It is possible to model nested hosting, for example a docker container running on a specific VM.




To create a reusable Container customization, create a sub-type:

Sample VDU sub-type - more details
# a more concrete VDU type onap.nodes.sample.MyCompute: derived_from: onap.nodes.Compute artifacts: container_image: type: tosca.artifacts.Deployment.Image.VM.ISO file: http://the.url.of/the.image.iso interfaces: Standard: start: implementation: image capabilities: host: type: onap.capabilities.Container requirements: - cpu: capability: onap.capabilities.infrastructure.CPU: occurrences: [0..UNBOUNDED] - 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]



A Container node in a VNF topology:

Container node
node_templates: container_123: type: onap.nodes.sample.MyContainer capabilities: host: # just saying... 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: - schema: http://json.schema.url



VFCs meet Containers:

VFCs meet VDUs






See also: Hardware Platform Requirements