...
| Code Block |
|---|
| language | text |
|---|
| title | ONAP Data Model Normatives |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
##################################
### ONAP Data Model Normatives ###
##################################
data_types:
interface_types:
onap.interfaces.node.lifecycle.Standard:
derived_from: tosca.interfaces.node.lifecycle.Standard
description: the ONAP resource lifecycle interface, in case it extends the standard TOSCA's
# here come the extensions
onap.interfaces.node.lifecycle.VNF:
# VNFs may need an extended lifecycle interface
onap.interfaces.node.lifecycle.Service:
# Services may need an extended lifecycle interface
capability_types:
onap.capabilities.Compute:
# .... a derivation of a TOSCA normative capability type
onap.capabilities.Storage:
# .... a derivation of a TOSCA normative capability type
policy_types:
onap.policies.scaling.Fixed:
# ....
onap.policies.scaling.Variable:
# ....
onap.policies.placement.Affinity:
# ....
onap.policies.placement.AntiAffinity:
# ....
onap.policies.naming.NumSequence:
# ....
node_types:
#TODO: provide a description of the metadata for the node templates
onap.nodes.Resource:
description: |
a base of the ONAP hierarchy of resources
derived_from: tosca.nodes.Root
requirements:
- host:
description: the very base of the|
An ONAP resource hierarchy may be hosted by a TOSCA container.
interfaces: In a VDU, this requirement is of the onap.capabilities.Compute type
Standard capability: tosca.capabilities.Container
# just a reminder that all resources have a standard lifecycle interface
occurrences: [0, 1]
typerelationship: onap.interfaces.node.lifecycle.Standardrelationship.HostedOn
onap.nodes.VNFFunction:
derived_from: onap.nodes.Resource
description: |
a virtual function (VNF, VDU, VFC)
descriptionproperties:
an abstract base# forall theIM hierarchyproperties
of concrete VNF resources
# all ECOMP VNF properties
requirements:
# 1. MANY requirements of type onap.capabilities.Compute (a summary of
# ECOMP's
# ONAP IM's
interfaces:
Standard: # just a reminder that
type: tosca.interfaces.node.lifecycle.VNF
requirements:
- compute:
the Compute requirements of all inner Container and VDU nodes
# exposed through the substitution mapping)
# 2. MANY requirements of type onap.capabilities.Linkable (a summary of
# the Linkable requirements of all ExtCPs inside the topology
# exposed through the substitution mapping)
# 3. MANY OTHER application-level reqs&caps
onap.nodes.VDU:
derived_from: onap.nodes.Resource
description: |
represents a virtualization container at the infrastructure level;
contains the software image,
declares [required] hardware capabilities
capabilities:
host:
type: onaptosca.capabilities.ComputeContainer
occurrences: [0, UNBOUNDED]
- storagecompute:
type: onap.capabilities.StorageCompute
occurrences: [0, UNBOUNDED]
#TODO: check on the HPA use case
storage:
type: onap.capabilities.Storage
occurrences: [0, UNBOUNDED]
|
| Code Block |
|---|
| language | text |
|---|
| title | Sample VNF |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
##################################
### Sample VNF ###
##################################
node_types:
com.vendorxxx.SampleVNF:
derived_from: onap.nodes.VNF
description: a concrete VNF provided by a vendor
properties:
num_of_instances_inside:
type: integer
requirements:
- compute_1:
type: onap.capabilities.Compute
- storage_1:
type: onap.capabilities.Storage
capabilities:
the_important_capability:
#...
topology_template:
inputs:
num_resource_instances:
description: how many resource instances to create
type: integer
node_templates:
vl_1:
cp_1:
internal_valuable_resource_1:
type: com.vendorxxx.ResourceType
artifacts:
image: ResourceDockerFile
capabilities:
valuable_capability: #....
requirements:
- computecontainer:
node: nodevdu_filter:1
capability: container
capabilities vdu_1:
type: onap.nodes.VDU
artifacts:
- onap.capabilities.Compute:
image: myImageFile.ovf
capabilities:
propertiescontainer:
compute:
num_cpus: {in_range: [2, 4]}
mem_size: {greater_or_equal: 1GB}
- storage:
#...
policies:
scale_the_value:
type: onap.policies.scaling.Fixed:
properties:
quantity: {get_input: num_resource_instances}
targets: [internal_valuable_resource_1]
separate_hosts:
type: onap.policies.placement.AntiAffinity
targets: [internal_valuable_resource_1]
properties:
distance: PhysicalHost
same_office:
type: onap.policies.placement.Affinity
targets: [internal_valuable_resource_1]
properties:
scope: DataCenter
substitution_mappings:
node_type: com.vendorxxx.SampleVNF
properties:
num_of_instances_inside:
mapping: [SELF, num_resource_instances] # a mapping to an input
capabilities:
the_important_capability:
mapping: [internal_valuable_resource_1, valuable_capability]
requirements:
compute_1:
mapping: [internal_valuable_resourcevdu_1, compute]
storage_1:
mapping: [internalvdu_valuable_resource_1, storage]
|
| Code Block |
|---|
| language | text |
|---|
| title | Service using the Vendor VNF |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
######################################
### A Sample Service using the Sample VNF ###
######################################
topology_template:
node_templates:
vnf_1:
type: com.vendorxxx.SampleVNF
properties:
num_of_instances_inside: 13
requirementscapabilities: # infrastructure requirements, to be sutisfiedsatisfied by the orchestrator
- compute:
node_filter_1:
capabilities:
- onap.capabilities.Compute:
properties- storage_1:
num_cpus: {in_range: [2, 4]}
mem_size: {greater_or_equal: 1GB}
capabilities: onap.capabilities.Storage
|
Points to emphasize:
- Scaling expressed through policies
- Affinity/anti-affinity expressed through policies
- VDU node type to model a virtual container (VM, Docker container):
- States quantified requirements for infrastructure:
- Generic requirements: computational power, storage volumes,
- Requirements for specific hardware: Intel’s, AMD, etc.
- Includes a software image used to initialize the container - as a TOSCA artifact
- In order to specify hardware/infrastructure requirements for a resource, the designer creates a VDU node in the topology template and then creates a relationship between the resource node and the VDU node using the tosca.capabilities.Container capability-requirement pair; multiple resources may share a VDU
- The requirements for hardware/infrastructure specified by the VDU nodes across the model will be satisfied on instantiation by the orchestrator.
- The VNFD element of the Information Model is modelled through a combination of the following TOSCA constructs:
- A TOSCA node type – the “interface” part of the definition: derived from the onap.nodes.VNF node type (and, consequently, from the basic onap.nodes.Resource); exposes the important properties, capabilities, requirements
- A TOSCA topology template – the “implementation” part of the definition: the internal topology of component resources and policies
- A TOSCA substitution mapping construct that wires the interface to the implementation: interface properties are mapped to the implementation topology inputs, interface capabilities and requirements – to those of the component resource nodes
- An occurrence of the VNF in a higher-level topology (a service or a “higher” VNF) is modelled as a TOSCA node template of the VNFD “interface” node type, with its properties populated and requirements and capabilities involved into relationships with the neighbor nodes.
See also: ECOMP SDC Metadata Overview, Affinity and AntiAffinity, Splitting VDU: VFC + Container,See also: Scaling
