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


  • No labels

10 Comments

  1. 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,  

    • Requirements are intentionally expressed as a sequenced list of TOSCA Requirement definitions which SHOULD be resolved (processed) in sequence order by TOSCA Orchestrators.

    so, according to that, maybe it is possible to set the priority of each requirement based on the sequence order.




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

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

    1. Anatoly Katzman

      Will share the VL model by Monday

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


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

      1. Anatoly Katzman

        "TOSCA doesn't let you define a requirement for multiple capabilities. We should explore adding this." - agree

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

  5. Anatoly Katzman

    Node type onap.nodes.Container has been renamed to onap.nodes.Compute for better alignment with the ETSI IFA terminology

  6. Phuoc Hoang

    Hi shitao li and Anatoly Katzman, do you guys have plan to support VNF node for Kubernetes?