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
  • No labels

8 Comments

  1. shitao li

    Hi  Anatoly


    is this the defintion of VDU?

  2. 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.

  3. 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?

  4. Michael Brenner

    I cannot find the 7.8.1.11 section in IFA011 - is it possible you referred to a different section?

  5. Andrei Kojukhov

    Yes, sorry. This should be 7.1.8.11.

  6. 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.

  7. 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?

  8. 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).