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:
- VFC - an ONAP resource that represents a piece of application-level logic and includes:
- a requirement for hosting by a container
- a software image to launch the application logic on the container
- a free set of application-level requirements and capabilities
- Container - an ONAP resource that represents a unit of infrastructure allocation. It expresses the following ideas:
- a "hardware shopping list" - in the terms of TOSCA requirements, which are based on specially designed TOSCA capability types
- a software image that the Orchestrator uses to launch such a unit - by means of a TOSCA artifact
- an ability to host application logic - modeled as a TOSCA capability of a special capability type
![](/download/attachments/24641738/VDUSeparationForSharing.png?version=1&modificationDate=1516731613000&api=v2)
![](/download/attachments/24641738/VDUSeparationForUpdate.png?version=1&modificationDate=1516732384000&api=v2)
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:
# 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:
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:
node_templates:
compute_123:
type: onap.nodes.Compute
capabilities:
host:
#....
vfc_1:
type: onap.nodes.Resource
requirements:
- host:
node: compute_123
capability: host
vfc_2:
type: onap.nodes.Resource
requirements:
- host:
node: compute_123
capability: host
See also: Hardware Platform Requirements
10 Comments
shitao li
Hi Anatoly
About the prioritizing issue of the requirements in VDU, I just check the tosca-simple-profile-yaml, it has the following statement,
so, according to that, maybe it is possible to set the priority of each requirement based on the sequence order.
Anatoly Katzman
Yes, this is one option. Srinivasa Addepalli also proposed a solution based on a score/weight property, similar to a feature existing in Kubernetes.
maopeng zhang
Hi Anatoly
1.About the CPU and memory requirements, please consider HPA feature NUMA. Suggest not make them seperated and merge them in to one structure.
numa requirement example:
hw:numa_nodes: "2"
hw:numa_cpus.0: "0,1"
hw:numa_mem.0: "1024"
hw:numa_cpus.1: "2,3,4,5"
hw:numa_mem.1: "1024"
2. How does the VDU connect to VL in the VNF?
Anatoly Katzman
Will share the VL model by Monday
Anatoly Katzman
The intent behind the separation between the requirements for CPU and those for memory was to make the data model more flexible. This way a model is able to express a requirement for a rare combination of CPUs made by vendor XXX and memory arrays of vendor YYY, it can subclass them separately, maybe give them different priorities.
I understand that in real life CPUs and memory are tightly coupled in most cases, and this NUMA configuration is yet another evidence of such a coupling. But "most cases" does not mean "always". What is important is that even with 2 separate requirements, a model can easily reflect a tightly coupled CPU+memory combination by populating these requirements with coherent types and their properties. "Borderline" configurations like NUMA can be just put on one of these 2 requirements (Memory, I guess). On the other hand, merging CPU and Memory requirements together will make impossible modeling of rare CPU-to-Memory combinations.
Chris Lauwers
I like the idea of separating out the requirements for different types of capabilities. What seems to be missing, however, is the fact that all those capabilities should be associated with the same node, and that fulfilling the requirement should result in only one single relationship (as opposed to multiple relationships, one for each target capability).
Unfortunately, TOSCA doesn't let you define a requirement for multiple capabilities. We should explore adding this.
Anatoly Katzman
"TOSCA doesn't let you define a requirement for multiple capabilities. We should explore adding this." - agree
shitao li
In the definition of
onap.nodes.Container, it has a long list of requirements, to fulfill those requirements, each one will use "node_filter" to describe the required resource information. According to the description of "node_filter" in TOSCA spec, it says that
"...use of the node_filter keyname to provide node and capability filtering information to find the “best match” of a concrete Node Template at run
I do not think that is what you intent to use in this model.
Another thing is that if I understand correctly, the onap.nodes.Container needs to have requirements for VM, Storage, IO and NIC, what lack in this model is the relationship among those resources, for example, in TOSCA, it defines the AttachesTo relationship between a VM(compute) and a storage, linksTo between a VM and a port. But here in onap.nodes.Container, those relationships are missing.
That is why in the alternative VDU method in TOSCA, we using a service template to describe the topology of the resources used in the VDU.
Anatoly Katzman
Node type onap.nodes.Container has been renamed to onap.nodes.Compute for better alignment with the ETSI IFA terminology
Phuoc Hoang
Hi user-7acab and Anatoly Katzman, do you guys have plan to support VNF node for Kubernetes?