diff options
Diffstat (limited to 'docs/Chapter5')
11 files changed, 175 insertions, 315 deletions
diff --git a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst index 4f2861f..fe5c877 100644 --- a/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst +++ b/docs/Chapter5/Heat/ONAP Heat Cinder Volumes.rst @@ -49,7 +49,7 @@ Module unless the Output Parameter is of the type ``comma_delimited_list``, then the corresponding input parameter **MUST** be declared as type ``json``. A volume template must define ``outputs`` for each Cinder volume resource -universally unique identifier (UUID) (i.e. ECOMP Volume Template Output +universally unique identifier (UUID) (i.e. ONAP Volume Template Output Parameters. - The VNF Incremental Module or Base Module must define input diff --git a/docs/Chapter5/Heat/ONAP Heat Networking.rst b/docs/Chapter5/Heat/ONAP Heat Networking.rst index 7591a97..79e39c6 100644 --- a/docs/Chapter5/Heat/ONAP Heat Networking.rst +++ b/docs/Chapter5/Heat/ONAP Heat Networking.rst @@ -58,40 +58,6 @@ independently of VNFs. use the port for the purpose of reaching VMs in the same VNF. .. req:: - :id: R-69014 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - When a VNF connects to an external network, a network role, referred to - as the ``{network-role}`` **MUST** be assigned to the external network for - use in the VNF's Heat Orchestration Template. - -.. req:: - :id: R-05201 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - When a VNF connects to two or more external networks, each external - network **MUST** be assigned a unique ``{network-role}`` - in the context of the VNF for use in the VNF's Heat Orchestration - Template. - -.. req:: - :id: R-83015 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - A VNF's ``{network-role}`` assigned to an external network **MUST** - be different than the ``{network-role}`` assigned to the VNF's - internal networks, if internal networks exist. - -.. req:: :id: R-99794 :target: VNF :keyword: MUST @@ -101,33 +67,9 @@ independently of VNFs. An external network **MUST** have one subnet. An external network **MAY** have more than one subnet. -Note that this document refers to ``{network-role}`` which in reality -is the ``{network-role-tag}``. The value of the -``{network-role}`` / ``{network-role-tag}`` -is determined by the designer of the VNF's Heat Orchestration Template and -there is no requirement for ``{network-role}`` / ``{network-role-tag}`` -uniqueness across Heat Orchestration Templates for -different VNFs. - -When an external network is created by ONAP, the network is assigned a -``{network-role}``. The ``{network-role}`` of the network is not required to -match the ``{network-role}`` of the VNF Heat Orchestration Template. - -For example, the VNF Heat Orchestration Template can assign a -``{network-role}`` -of ``oam`` to a network which attaches to an external network with a -``{network-role}`` of ``oam_protected_1`` . - -When the Heat Orchestration Template is on-boarded into ONAP - * each ``{network-role}`` value in the Heat Orchestration Template - is mapped to the ``{network-role-tag}`` in the ONAP - data structure. - * each ``OS::Neutron::Port`` is associated with the external network it is - connecting to, thus creating the VNF Heat Orchestration Template - ``{network-role}`` / ``{network-role-tag}`` - to external network ``{network-role}`` mapping. - -ONAP enforces a naming convention for parameters associated with +ONAP enforces a naming convention for +resource IDs and resource property +parameters associated with external networks. :ref:`ONAP Heat Resource ID and Parameter Naming Convention` provides additional details. @@ -195,39 +137,6 @@ Contrail Heat Resources. external router. .. req:: - :id: R-68936 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - When a VNF creates an internal network, a network role, referred to as - the ``{network-role}`` **MUST** be assigned to the internal network - for use in the VNF's Heat Orchestration Template. - -.. req:: - :id: R-32025 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - When a VNF creates two or more internal networks, each internal - network **MUST** be assigned a unique ``{network-role}`` in the context - of the VNF for use in the VNF's Heat Orchestration Template. - -.. req:: - :id: R-69874 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - A VNF's ``{network-role}`` assigned to an internal network **MUST** - be different than the ``{network-role}`` assigned to the VNF's external - networks. - -.. req:: :id: R-16241 :target: VNF :keyword: MUST diff --git a/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst b/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst index edc3b34..a97827c 100644 --- a/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst +++ b/docs/Chapter5/Heat/ONAP Heat Orchestration Template Format.rst @@ -786,20 +786,3 @@ ONAP implementation does not support the Environment File resource_registry section. The resource_registry section allows for the definition of custom resources. -SDC Treatment of Environment Files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Parameter values enumerated in the environment file are used by SDC as -the default value. However, the SDC user may use the SDC GUI to -overwrite the default values in the environment file. - -SDC generates a new environment file for distribution to MSO based on -the uploaded environment file and the user provided GUI updates. The -user uploaded environment file is discarded when the new file is -created. - -ONAP has requirements for what parameters must be enumerated in the -environment file and what parameter must not be enumerated in the -environment file. See :ref:`Output Parameters` and -:ref:`ONAP Heat Resource ID and Parameter Naming Convention` for more details. - diff --git a/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst b/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst index acc9ef3..f1e2b4e 100644 --- a/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst +++ b/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst @@ -60,15 +60,6 @@ deployed incrementally to create the complete VNF. A VNF **MAY** be composed of zero to many Incremental Modules. .. req:: - :id: R-20974 - :target: VNF - :keyword: MUST - :updated: casablanca - - At orchestration time, the VNF's Base Module **MUST** - be deployed first, prior to any incremental modules. - -.. req:: :id: R-28980 :target: VNF :keyword: MAY @@ -575,3 +566,41 @@ Orchestration Template at orchestration time. A VNF's Heat Orchestration Template's parameter values that are constant across all deployments **MUST** be declared in a Heat Orchestration Template Environment File. + +ONAP VNF On-Boarding +^^^^^^^^^^^^^^^^^^^^ + +.. req:: + :id: R-511776 + :keyword: MUST + + When a VNF's Heat Orchestration Template is ready + to be on-boarded to ONAP, + all files composing the VNF Heat Orchestration Template + **MUST** be placed in a flat (i.e., non-hierarchical) directory and + archived using ZIP. The resulting ZIP file is uploaded into ONAP. + +The VNF's Heat Orchestration Template's ZIP file must include +the base module YAML file (R-37028) and corresponding environment file +(R-38474). + +The VNF's Heat Orchestration Template's ZIP file **MAY** include + +* One or more incremental module YAML files (R-13196) and corresponding + environment files (R-81725). +* One or more volume module YAML files (R-03251) and corresponding + environment files (R-53433). +* One or more nested YAML files (R-36582, R-56721, R-30395). +* One or more files that are retrieved via the intrinsic function + ``get_file``. The ``get_file`` function returns the content of a file + into a Heat Orchestration Template. It is generally used as a file + inclusion mechanism for files containing scripts or configuration files. + (See Section 9.3) + +.. req:: + :id: R-348813 + :keyword: MUST + + The VNF's Heat Orchestration Template's ZIP file **MUST NOT** include + a binary image file. + diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst index 1fbdec7..8a31cad 100644 --- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst +++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Contrail Resource Parameters.rst @@ -234,7 +234,7 @@ instance_ip_address* The property instance_ip_address uses the same parameter naming convention as the property fixed_ips and Map Property ip_address in -OS::Neutron::Port. The resource is assigning an ECOMP SDN-C Assigned IP +OS::Neutron::Port. The resource is assigning an ONAP SDN-C Assigned IP Address. The {network-role} has been defined as oam_protected to represent an oam protected network and the {vm-type} has been defined as fw for firewall. diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst index 948f8aa..4342bb0 100644 --- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst +++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Neutron Parameters.rst @@ -62,40 +62,15 @@ This will be described in the forth coming sections. Items to Note ~~~~~~~~~~~~~~ -.. req:: - :id: R-93272 - :target: VNF - :keyword: MAY - :updated: casablanca - - A VNF **MAY** have one or more ports connected to a unique - external network. All VNF ports connected to the unique external - network **MUST** have cloud assigned IP Addresses - or **MUST** have ONAP SDN-C assigned IP addresses. - -.. req:: - :id: R-13841 - :target: VNF - :keyword: MAY - :updated: casablanca - - A VNF **MAY** have one or more ports connected to a unique - internal network. All VNF ports connected to the unique internal - network **MUST** have cloud assigned IP Addresses - or **MUST** have statically assigned IP addresses. - -.. req:: - :id: R-07577 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca +A VNF **MAY** have one or more ports connected to a unique +external network. All VNF ports connected to the unique external +network **MUST** have cloud assigned IP Addresses +or **MUST** have ONAP SDN-C assigned IP addresses. - If the VNF's ports connected to a unique network (internal or external) - and the port's IP addresses are cloud assigned IP Addresses, - all the IPv4 Addresses **MUST** be from - the same subnet and all the IPv6 Addresses **MUST** be from the - same subnet. +A VNF **MAY** have one or more ports connected to a unique +internal network. All VNF ports connected to the unique internal +network **MUST** have cloud assigned IP Addresses +or **MUST** have statically assigned IP addresses. .. req:: :id: R-45602 @@ -165,6 +140,25 @@ Items to Note * property ``fixed_ips`` map property ``subnet`` **MUST NOT** be used +.. req:: + :id: R-681859 + :keyword: MUST + + A VNF's Heat Orchestration Template's ``OS::Neutron::Port`` resource's + + * Resource ID (defined in R-20453) + * property ``network`` parameter name (defined in R-62983 and + R-86182) + * property ``fixed_ips``, map property ``ip_address`` parameter name + (defined in R-40971, R-04697, R-71577, R-23503, R-78380, R-85235, + R-27818, and R-29765) + * property ``fixed_ips``, map property ``subnet`` parameter name + (defined in R-62802, R-15287, R-84123, R-76160) + * property ``allowed_address_pairs`` parameter name (defined in + R-41492 and R-83418) + + **MUST** contain the identical ``{network-role}``. + Property: network ^^^^^^^^^^^^^^^^^^ @@ -1048,6 +1042,10 @@ The property ``fixed_ips`` is used to assign IPs to a port. The Map Property * ``{network-role}`` is the network role of the network. + +Note that ONAP only supports cloud assigned IP addresses from one IPv4 subnet +of a given network. + .. req:: :id: R-83677 :target: VNF @@ -1100,6 +1098,9 @@ value at orchestration to the Heat Orchestration Template. * ``{network-role}`` is the network role of the network. +Note that ONAP only supports cloud assigned IP addresses from one IPv6 subnet +of a given network. + .. req:: :id: R-80829 :target: VNF diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst index b5501fd..f861615 100644 --- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst +++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/Nova Parameters.rst @@ -35,15 +35,21 @@ Requirement R-82481 defines how the ``{vm-type}`` is used. A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource's - * Resource ID - * property ``image`` parameter name - * property ``flavor`` parameter name - * property ``name`` parameter name - + * Resource ID (defined in R-29751) + * property ``image`` parameter name (defined in R-58670) + * property ``flavor`` parameter name (defined in R-45188) + * property ``name`` parameter name (defined in R-54171 & R-87817) + * property port referenced OS::Neutron::Port Resource ID + (defined in R-58670) **MUST** contain the identical ``{vm-type}`` and **MUST** follow the naming conventions defined - in R-58670, R-45188, R-54171, R-87817, and R-29751. + in R-58670, R-45188, R-54171, R-87817, and R-29751. And the ``{index}`` in + the ``OS::Nova::Server`` Resource ID (defined in R-29751) **MUST** match + the ``{vm-type_index}`` defined in + the ``OS::Nova::Server`` property ``port`` + referenced ``OS::Neutron::Port`` Resource ID. + The table below provides a summary. The sections that follow provides the detailed requirements. @@ -241,18 +247,6 @@ Property: Name zero and increments by one. .. req:: - :id: R-40899 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` - property ``name`` parameter is defined as a ``string``, a parameter - **MUST** be delcared for - each ``OS::Nova::Server`` resource associated with the ``{vm-type}``. - -.. req:: :id: R-87817 :target: VNF :keyword: MUST @@ -265,18 +259,6 @@ Property: Name ``{vm-type}_names``. .. req:: - :id: R-85800 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` - property ``name`` parameter is defined as a ``comma_delimited_list``, - a parameter **MUST** be delcared once for all ``OS::Nova::Server`` resources - associated with the ``{vm-type}``. - -.. req:: :id: R-22838 :target: VNF :keyword: MUST NOT diff --git a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/{network-role}.rst b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/{network-role}.rst index 48ca384..134c383 100644 --- a/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/{network-role}.rst +++ b/docs/Chapter5/Heat/ONAP Heat Resource ID and Parameter Naming Convention/{network-role}.rst @@ -5,8 +5,31 @@ {network-role} ----------------------------- -The assignment of a {network-role} is discussed in -:ref:`ONAP Heat Networking`. +.. req:: + :id: R-69014 + :target: VNF + :keyword: MUST + :validation_mode: static + :updated: casablanca + + When a VNF's port connects to an internal network or external network, + a network role, referred to + as the ``{network-role}`` **MUST** be assigned to the network for + use in the VNF's Heat Orchestration Template. The ``{network-role}`` + is used in the VNF's Heat Orchestration Template resource IDs + and resource property parameter names. + +.. req:: + :id: R-05201 + :target: VNF + :keyword: MUST + :validation_mode: static + :updated: casablanca + + When a VNF connects to two or more unique networks, each + network **MUST** be assigned a unique ``{network-role}`` + in the context of the VNF for use in the VNF's Heat Orchestration + Template. .. req:: :id: R-21330 @@ -108,3 +131,30 @@ For example, if a VNF has a '{vm-type}' of 'oam' and a A VNF's Heat Orchestration Template's ``{network-role}`` case in Resource property parameter names **SHOULD** match the case of ``{network-role}`` in Resource IDs and vice versa. + + +Note that this document refers to ``{network-role}`` which in reality +is the ``{network-role-tag}``. The value of the +``{network-role}`` / ``{network-role-tag}`` +is determined by the designer of the VNF's Heat Orchestration Template and +there is no requirement for ``{network-role}`` / ``{network-role-tag}`` +uniqueness across Heat Orchestration Templates for +different VNFs. + +When an external network is created by ECOMP, the network is also assigned a +``{network-role}``. The ``{network-role}`` of the network is not required to +match the ``{network-role}`` of the VNF Heat Orchestration Template. + +For example, the VNF Heat Orchestration Template can assign a +``{network-role}`` +of ``oam`` to a network which attaches to an external network with a +``{network-role}`` of ``oam_protected`` . + +When the Heat Orchestration Template is on-boarded into ECOMP + * each ``{network-role}`` value in the Heat Orchestration Template + is mapped to the ``{network-role-tag}`` in the ECOMP + data structure. + * each ``OS::Neutron::Port`` is associated with the external network it is + connecting to, thus creating the VNF Heat Orchestration Template + ``{network-role}`` / ``{network-role-tag}`` + to external network ``{network-role}`` mapping. diff --git a/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst b/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst index 35286f0..e8117ad 100644 --- a/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst +++ b/docs/Chapter5/Heat/ONAP Heat Support of Environment Files.rst @@ -7,63 +7,4 @@ ONAP Heat Support of Environment Files ----------------------------------------- -The use of an environment file in OpenStack is optional. In ONAP, it is -mandatory. A Heat Orchestration Template uploaded to ONAP must have a -corresponding environment file, even if no parameters are required to -be enumerated. - -*(Note that ONAP does not programmatically enforce the use of -an environment file.)* - -As stated in :need:`R-38474`, :need:`R-81725`, and :need:`R-53433`: - - - * A VNF's Base Module **MUST** have a corresponding Environment File. - * A VNF's Incremental Module **MUST** have a corresponding Environment File. - * A VNF's Cinder Volume Module **MUST** have a corresponding environment - File. - -A nested heat template must not have an environment file; OpenStack does -not support it. - -The environment file must contain parameter values for the ONAP -Orchestration Constants and VNF Orchestration Constants. These -parameters are identical across all instances of a VNF type, and -expected to change infrequently. The ONAP Orchestration Constants are -associated with OS::Nova::Server image and flavor properties (See -:ref:`Property image` and :ref:`Property flavor`). Examples of VNF -Orchestration Constants are the networking parameters associated -with an internal network (e.g., private IP ranges) and Cinder -volume sizes. - -The environment file must not contain parameter values for parameters -that are instance specific (ONAP Orchestration Parameters, VNF -Orchestration Parameters). These parameters are supplied to the Heat by -ONAP at orchestration time. - -SDC Treatment of Environment Files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Parameter values enumerated in the environment file are used by SDC as -the default value. However, the SDC user may use the SDC GUI to -overwrite the default values in the environment file. - -SDC generates a new environment file for distribution to SO based on -the uploaded environment file and the user provided GUI updates. The -user uploaded environment file is discarded when the new file is -created. Note that if the user did not change any values via GUI -updates, the SDC generated environment file will contain the same values -as the uploaded file. - -Use of Environment Files when using OpenStack "heat stack-create" CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When ONAP is instantiating the Heat Orchestration Template, certain -parameter must not be enumerated in the environment file. This document -provides the details of what parameters should not be enumerated. - -If the Heat Orchestration Template is to be instantiated from the -OpenStack Command Line Interface (CLI) using the command "heat -stack-create", all parameters must be enumerated in the environment -file. - +<section deleted> diff --git a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst index ce2c1e4..1af326e 100644 --- a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst +++ b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst @@ -10,7 +10,7 @@ ONAP Heat Heat Template Constructs .. _Nested Heat Templates: Nested Heat Templates -^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^ ONAP supports nested Heat templates per the OpenStack specifications. Nested templates may be suitable for larger VNFs that contain many @@ -21,7 +21,7 @@ either statically by repeated definition or dynamically by using the resource OS::Heat::ResourceGroup. Nested Heat Template Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ONAP supports nested Heat Orchestration Templates. @@ -79,16 +79,6 @@ As stated in requirement :need:`R-99646`, a VNF's YAML files (i.e, Heat Orchestration Template files and Nested files) **MUST** have a unique name in the scope of the VNF. -.. req:: - :id: R-52530 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - A VNF's Heat Orchestration Template's Nested YAML file - **MUST** be in the same directory hierarchy as the VNF's Heat - Orchestration Templates. .. req:: :id: R-90022 @@ -164,17 +154,13 @@ Template's ``OS::Nova::Server`` Resource ``metadata`` map value parameter ``environment_context`` is passed into a Nested YAML file, the parameter name ``environment_context`` **MUST NOT** change. -With nested templates, outputs are required to expose any resource -properties of the child templates to the parent template. Those would -not explicitly be declared as parameters but simply referenced as -``get_attribute`` targets against the "parent" resource. - -A parameter declared in the outputs: section of a nested template can -be accessed from the parent template as an attribute (i.e., via -``get_attr``) of the "pseudo resource" whose type is in the nested -template. In the case of a ``OS::Heat::ResourceGroup``, an output will be -an attribute of the ``OS::Heat::ResourceGroup`` itself, and will be an -array from the perspective of the parent template. +If a VNF's Heat Orchestration Template's nested YAML file is +required to expose a resource property to the invoking Heat Orchestration +Template, an ``outputs:`` statement +must be used in the nested YAML file. The invoking template +references the property by using the intrinsic function ``get_attr`` +that targets the resource invoking the nested YAML file and references +the parameter defined in the ``outputs`` section. .. req:: :id: R-17528 @@ -189,7 +175,7 @@ array from the perspective of the parent template. **MUST NOT** contain an ``OS::Nova::Server`` resource. Nested Heat Template Example: Static -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ incremental.yaml @@ -252,10 +238,10 @@ nested.yaml metadata: vnf_id: { get_param: vnf_id } vf_module_id: { get_param: vf_module_id } - vnf_name {get_param: vnf_name } + vnf_name: {get_param: vnf_name } Use of Heat ResourceGroup -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~ The OS::Heat::ResourceGroup is a useful Heat element for creating multiple instances of a given resource or collection of resources. @@ -315,7 +301,7 @@ You can then reference within the nested template as: { get_param: [names, {get_param: index} ] } OS::Heat::ResourceGroup Property count -++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++ .. req:: @@ -345,7 +331,7 @@ This is required for ONAP to build the TOSCA model for the VNF. index: index Availability Zone and ResourceGroups -++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++ The resource OS::Heat::ResourceGroup and the property availability_zone has been an "issue" with a few VNFs since ONAP only supports @@ -439,12 +425,12 @@ az_list_generate.yaml { get_param: availability_zone_0 }, { get_param: availability_zone_1 }, { get_param: availability_zone_0 }, - { get_param: availability_zone_1 }, + { get_param: availability_zone_1 } ] Nested Heat Template Example: OS::Heat::ResourceGroup -++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++ In this example, ocgapp_volume.yml creates volumes using a OS::Heat::ResourceGroup that uses nested heat by calling @@ -597,7 +583,7 @@ ocgapp.yml instance_uuid: {get_resource: ocgapp_server_1} External References -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^ Heat templates *must not* reference any HTTP-based resource definitions, any HTTP-based nested configurations, or any HTTP-based @@ -626,15 +612,14 @@ information. The purpose of using an URI is to give the namespace a unique name. Heat Files Support (get_file) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Heat Templates may contain the inclusion of text files into Heat -templates via the Heat get_file directive. This may be used, for -example, to define a common "user-data" script, or to inject files into -a VM on startup via the "personality" property. - -Support for Heat Files is subject to the following limitations: +A VNF's Heat Orchestration Template may contain the inclusion of text files +containing scripts or configuration files. The ``get_file`` intrinsic +function returns the content of a file into a Heat Orchestration Template. +The support for the ``get_file`` intrinsic function in ONAP is subject to the +following limitations: .. req:: :id: R-76718 @@ -647,9 +632,9 @@ Support for Heat Files is subject to the following limitations: ``get_file``, the ``get_file`` target **MUST** be referenced in the Heat Orchestration Template by file name. -The ``get_file`` target files are on-boarded to SDC in the same package +The ``get_file`` target files are on-boarded to SDC in the same zip file that contains the VNF's complete Heat Orchestration Template. - +See requirement R-511776. .. req:: :id: R-41888 @@ -661,21 +646,6 @@ that contains the VNF's complete Heat Orchestration Template. A VNF's Heat Orchestration Template intrinsic function ``get_file`` **MUST NOT** utilize URL-based file retrieval. -.. req:: - :id: R-87848 - :target: VNF - :keyword: MUST - :validation_mode: static - :updated: casablanca - - When using the intrinsic function get_file, ONAP does not support - a directory hierarchy for included files. All files must be in a - single, flat directory per VNF. A VNF's Heat Orchestration - Template's ``get_file`` target files **MUST** be in the same - directory hierarchy as the VNF's Heat Orchestration Templates. - -ONAP does not support a hierarchical structure. A VNF's YAML files -must be in a single, flat directory. .. req:: :id: R-05050 @@ -691,7 +661,7 @@ must be in a single, flat directory. * in a VNF's Heat Orchestration Templates nested YAML file Key Pairs -^^^^^^^^^^ +^^^^^^^^^ When Nova Servers are created via Heat templates, they may be passed a "keypair" which provides an ssh key to the 'root' login on the newly @@ -756,7 +726,7 @@ of lb (for load balancer)):* save_private_key: false Security Groups -^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^ OpenStack allows a tenant to create Security groups and define rules within the security groups. @@ -771,7 +741,7 @@ network or it can vary by VM (i.e., {vm-type}) and network type (i.e., {network-role}). Anti-Affinity and Affinity Rules -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Anti-affinity or affinity rules are supported using normal OpenStack OS::Nova::ServerGroup resources. Separate ServerGroups are typically @@ -828,7 +798,7 @@ balancer and db for database. group: {get_resource: lb_server_group} Resource Data Synchronization -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For cases where synchronization is required in the orchestration of Heat resources, two approaches are recommended: @@ -893,5 +863,3 @@ oam server. volume_id: {get_param: oam_vol_1} mountpoint: /dev/vdb instance_uuid: {get_resource: oam_server_01} - - diff --git a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst index 23ce06b..ae44870 100644 --- a/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst +++ b/docs/Chapter5/Heat/ONAP Heat VNF Modularity.rst @@ -22,7 +22,7 @@ As stated in :need:`R-33132`, a VNF's Heat Orchestration Template **MAY** be 3. a Cinder Volume Module Heat Orchestration Template (referred to as Cinder Volume Module). -As stated in :need:`R-20974`, at orchestration time, the VNF's Base +At orchestration time, the VNF's Base Module **MUST** be deployed first, prior to any incremental modules. As stated in :need:`R-28980`, :need:`R-86926`, and :need:`R-91497`, a @@ -36,12 +36,9 @@ As stated in :need:`R-68122`, a VNF's incremental module **MAY** be deployed more than once, either during initial VNF deployment and/or scale out As stated in :need:`R-37028` and :need:`R-13196`, a VNF **MUST** be composed -of one Base Module and *MAY** be composed of zero to many Incremental +of one Base Module and **MAY** be composed of zero to many Incremental Modules. -As stated in :need:`R-20974`, at orchestration time, the VNF's Base Module -**MUST** be deployed first, prior to any incremental modules. - ONAP also supports the concept of an optional, independently deployed Cinder volume via a separate Heat Orchestration Templates, referred to as a Cinder Volume Module. This allows the volume to persist after a VM @@ -73,12 +70,12 @@ Incremental Module. exposed by declaring a parameter in the ``outputs`` section of the base module. - For ECOMP to provided the UUID value of the shared resource to the + For ONAP to provided the UUID value of the shared resource to the incremental module, the parameter name defined in the ``outputs`` section of the base module **MUST** be defined as a parameter in the ``parameters`` section of the incremental module. - ECOMP will capture the output parameter name and value in the base module + ONAP will capture the output parameter name and value in the base module and provide the value to the corresponding parameter(s) in the incremental module(s). |