diff options
Diffstat (limited to 'docs/Chapter5.rst')
| -rw-r--r-- | docs/Chapter5.rst | 106 |
1 files changed, 53 insertions, 53 deletions
diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst index 4c2490e..2c37fb2 100644 --- a/docs/Chapter5.rst +++ b/docs/Chapter5.rst @@ -9,8 +9,8 @@ Introduction ------------- This reference document is the VNF TOSCA Template Requirements for -OpenO, which provides recommendations and standards for building VNF -TOSCA templates compatible with OpenO– initial implementations of +ONAP, which provides recommendations and standards for building VNF +TOSCA templates compatible with ONAP initial implementations of Network Cloud. It has the following features: 1. VNF TOSCA template designer supports GUI and CLI. @@ -25,26 +25,26 @@ Intended Audience ----------------- This document is intended for persons developing VNF TOSCA templates -that will be orchestrated by OpenO. +that will be orchestrated by ONAP. -Scope ------- +Scope +----- -OpenO implementations of Network Cloud supports TOSCA Templates, also +ONAP implementations of Network Cloud supports TOSCA Templates, also referred to as TOSCA in this document. -OpenO requires the TOSCA Templates to follow a specific format. This +ONAP requires the TOSCA Templates to follow a specific format. This document provides the mandatory, recommended, and optional requirements associated with this format. -Overview +Overview --------- The document includes three charters to help the VNF vendors to use the VNF model design tools and understand the VNF package structure and VNF TOSCA templates. -In the OPENO, VNF Package and VNFD template can be designed by manually +In the ONAP, VNF Package and VNFD template can be designed by manually or via model designer tools. VNF model designer tools can provide the GUI and CLI tools for the VNF vendor to develop the VNF Package and VNFD template. @@ -59,7 +59,7 @@ self-defined node or other extensions. NFV TOSCA Template ------------------ -TOSCA templates supported by OPENO must follow the requirements +TOSCA templates supported by ONAP must follow the requirements enumerated in this section. TOSCA Introduction @@ -84,7 +84,7 @@ Node Template references a Node Type and adds usage constraints, such as how many times the component can occur. |image1| -Figure 1: Structural Elements of Service Template and their Relations +Figure 1: Structural Elements of Service Template and their Relations TOSCA Modeling Principles & Data Model -------------------------------------- @@ -653,7 +653,7 @@ Definition Artifact ^^^^^^^^ +-----------+------------+-------------------------------+---------------+------------------------------------------------+ -| Name | Required | Type | Constraints | Description | +| Name | Required | Type | Constraints | Description | +===========+============+===============================+===============+================================================+ | SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is | | | | | | directly realizing this virtual storage | @@ -770,12 +770,12 @@ Properties +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ -| Name | Required | Type | Constraints | Description | +| Name | Required | Type | Constraints | Description | +===============================+============+==========================================+==========================================================================+ -| bitrate_requirement | no | integer | | Bitrate requirement on this connection point. | +| bitrate_requirement | no | integer | | Bitrate requirement on this connection point. | +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ | virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network | -| requirements | | | | realising the CPs instantiated from this CPD | +| requirements | | | | realising the CPs instantiated from this CPD | +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ Attributes @@ -1578,25 +1578,25 @@ https://docs.openstack.org/developer/heat/template_guide/hot_spec.html. .. code-block:: python - heat_template_version: <date> - - description: - # a description of the template - - parameter_groups: - # a declaration of input parameter groups and order - - parameters: - # declaration of input parameters - - resources: - # declaration of template resources - - outputs: - # declaration of output parameters - - conditions: - # declaration of conditions + heat_template_version: <date> + + description: + # a description of the template + + parameter_groups: + # a declaration of input parameter groups and order + + parameters: + # declaration of input parameters + + resources: + # declaration of template resources + + outputs: + # declaration of output parameters + + conditions: + # declaration of conditions Heat Orchestration templates for ONAP must contain the following @@ -2344,7 +2344,7 @@ When the internal network is created, it should be assigned a unique {network-role} in the context of the VNF. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details. -VNFs may use **Cloud assigned IP addresses** or +VNFs may use **Cloud assigned IP addresses** or **predetermined static IPs** when attaching VMs to an internal network. - A Cloud assigned IP address is assigned by OpenStack’s DHCP Service. @@ -3078,8 +3078,8 @@ In this example, the {vm-role} is enumerated in the environment file. metadata: vm_role: { get_param: vm_role } -Example -~~~~~~~~ +Example +~~~~~~~ The example below depicts part of a Heat Orchestration Template that uses the five of the OS::Nova::Server metadata parameter discussed in @@ -3502,7 +3502,7 @@ The parameter must not be enumerated in the Heat environment file. .. code-block:: python parameters: - + {vm-type}_{network-role}_ips: type: comma_delimited_list description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network @@ -3844,7 +3844,7 @@ an oam network and the {vm-type} has been defined as db for database. db_oam_floating_ip: type: string description: VIP IP for db VMs on the oam network - + resources: db_0_port_0: type: OS::Neutron::Port @@ -4086,15 +4086,15 @@ ONAP Output Parameter Names ONAP defines three types of Output Parameters as detailed in `Output Parameters`_. -ONAP Base Module Output Parameters: -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +ONAP Base Module Output Parameters: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ONAP Base Module Output Parameters do not have an explicit naming convention. The parameter name must contain {vm-type} and {network-role} when appropriate. -ONAP Volume Template Output Parameters: -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +ONAP Volume Template Output Parameters: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ONAP Base Module Output Parameters do not have an explicit naming convention. The parameter name must contain {vm-type} when appropriate. @@ -4225,8 +4225,8 @@ ONAP requires the parameter names of certain Contrail Resources to follow specific naming conventions. This section provides these requirements. -Contrail Network Parameters -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Contrail Network Parameters +~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contrail based resources may require references to a Contrail network using the network FQDN. @@ -4393,7 +4393,7 @@ represent an oam protected network and the {vm-type} has been defined as virtual_network_refs: - get_param: oam_protected_net_fqdn subnet_uuid: { get_param: oam_protected_subnet_id } - + Cinder Volume Templates ----------------------- @@ -4997,8 +4997,8 @@ balancer and db for database. scheduler_hints: group: {get_resource: lb_server_group} -Resource Data Synchronization ------------------------------- +Resource Data Synchronization +----------------------------- For cases where synchronization is required in the orchestration of Heat resources, two approaches are recommended: @@ -5067,7 +5067,7 @@ oam server. mountpoint: /dev/vdb instance_uuid: {get_resource: oam_server_01} -High Availability +High Availability ----------------- VNF/VM parameters may include availability zone IDs for VNFs that @@ -5097,14 +5097,14 @@ c. VNFM Driver Develop Steps ============================== Aid to help the VNF vendor to fasten the integration with the NFVO via -Special VNFM, the OpenO provides the documents. In this charter, the +Special VNFM, the ONAP provides the documents. In this charter, the develop steps for VNF vendors will be introduced. First, using the VNF SDK tools to design the VNF with TOSCA model and output the VNF TOSCA package. The VNF package can be validated, and tested. -Second, the VNF vendor should provide SVNFM Driver in the OpenO, which +Second, the VNF vendor should provide SVNFM Driver in the ONAP, which is a micro service and in duty of translation interface from NFVO to SVNFM. The interface of NFVO is aligned to the ETSI IFA interfaces and can be gotten in the charter 5.5. The interface of SVNFM is provided by @@ -5113,7 +5113,7 @@ the VNF vendor self. d. Create SVNFM Adaptor Mircoservice ======================================= -Some vnfs are managed by special vnfm, before add svnfm to openo, a +Some vnfs are managed by special vnfm, before add svnfm to ONAP, a svnfm adaptor must be added to openo to adapter the interface of nfvo and svnfm. @@ -5149,4 +5149,4 @@ POST /openoapi/microservices/v1/services ] - }
\ No newline at end of file + } |