Nodes of this type represent a virtualization container, such as a VM or a Docker container.
Used to express advanced VNFC deployment scenarios, such as:
- Multiple VDUs sharing a container and its hardware resources
- Stacking software images
Definition
node_types: onap.nodes.Compute: description: | a virtualization container derived_from: onap.nodes.Resource artifacts: sw_image: type: tosca.artifacts.Deployment description: | a software image used to launch an instance of the virtualization container capabilities: host: type: tosca.capabilities.Container occurrences: [1, UNBOUNDED] # a container can host one or more VDUs requirements: - host: capability: onap.capabilities.Compute description: hardware required to function relationship: onap.relationships.HostedOn occurrences: [1,1] - storage: capability: onap.capabilities.Storage description: an attached storage device required for the container to function relationship: tosca.relationships.AttachesTo
8 Comments
shitao li
Hi Anatoly
is this the defintion of VDU?
Michael Brenner
Here is my understanding: this is not the VDU, but rather a container (VM, Docker, whatever) that can realize a VDU. In this approach there is no such thing as a generic VDU node type. The VDU is specific to the vendor, and can carry any name the vendor wants. The VDU model is under Monolyth or Composite pattern (see examples Monolyth pattern for VDU does not require explicitly the container, since it assumes there is a single VM per compute, and all VDUs will be in a single VM (it's not consistent with the ETSI NFV notion of VDU, but tries to accomodate the notion of multiple VNFCs in a single VM (VDU)). Composite pattern allows to specify a "container" requirement per VDU - which would map into the ETSI NFV approach. Between the 2 patterns multiple cases can be covered. Of course - if we need to represent the VDU much closer to everything that a VDU is defined as in ETSI NFV, more work is needed.
Andrei Kojukhov
How this approach deviates from IFA011 sub-clause 7.8.1.11 defining (at least to my understanding) the grouping of VDU's on a single container?
Michael Brenner
I cannot find the 7.8.1.11 section in IFA011 - is it possible you referred to a different section?
Andrei Kojukhov
Yes, sorry. This should be 7.1.8.11.
Michael Brenner
Section 7.1.8.11 addresses a different issue - of affinity or anti-affinity (between VDUs, VLs, ...). In the proposed ONAP approach that would be addressed via policies. The Composite pattern to define VDUs proposed in ONAP only addresses the way to allow multiple VDUs in the same host - it intentionally does not address which such VDUs to allow (or disallow) - which will be done via affinity and/or anti-affinity policy.
Andrei Kojukhov
I see, however I'm still struggling to understand a concern: a lack of specification in IFA011 to describe a deployment of multiple VNF-C's on single VM? Is it a correct understanding?
Michael Brenner
Yes, that is correct. In IFA011, the design is supporting the notion of 1 VNFC match per VDU/container (VM). If you have multiple VNFC for that VNF you have 2 choices: place them all in the same VDU/container (1 joint s/w image for all VNFCs) or separate them 1 vNFC per VDU/container (1 s/w image per VDU).