-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-**Appendix**
-===============
+Appendix
+========
Chef JSON Key Value Description
-------------------------------------
+---------------+----------------------+---------+----------------------------+
| **Field Name**| **Description** | **Type**| **Comment** |
+===============+======================+=========+============================+
-| PlaybookName | VNF providor must |Mandatory| |
-| | list name of the | | |
-| | playbook used to | | |
-| | execute the VNF | | |
-| | action. | | |
+| PlaybookName | VNF providor must |Mandatory|Currently following |
+| | list name of the | |Ansible standard |
+| | playbook relative | |naming, where main |
+| | path used to | |playbook is always |
+| | execute the VNF | |named site.yml, and |
+| | action. | |directory name where |
+| | | |this main playbook resides, |
+| | | |is named after the |
+| | | |command/action playbook |
+| | | |performs, in lower case, |
+| | | |example, configure. |
+---------------+----------------------+---------+----------------------------+
| Action | Name of VNF action. | Optional| |
+---------------+----------------------+---------+----------------------------+
-| EnvParameters | A JSON dictionary | Optional| Depends on the VNF action. |
+| EnvParameters | A JSON dictionary | Optional|Depends on the VNF action. |
| | which should list key| | |
-| | value pairs to be | | |
-| | passed to the Ansible| | |
-| | playbook. These | | |
-| | values would | | |
-| | correspond to | | |
-| | instance specific | | |
-| | parameters that a | | |
-| | playbook may need to | | |
+| | value pairs to be | |Attribute names (variable |
+| | passed to the Ansible| |names) passed to Ansible |
+| | playbook. These | |shall follow Ansible valid |
+| | values would | |variable names: “Variable |
+| | correspond to | |names should be letters, |
+| | instance specific | |numbers, and underscores. |
+| | parameters that a | |Variables should always |
+| | playbook may need to | |start with a letter.” |
| | execute an action. | | |
+---------------+----------------------+---------+----------------------------+
-| NodeList | A JSON array of FQDNs| Optional| If not provided, playbook |
-| | that the playbook | | will be executed on the |
-| | must be executed on. | | Ansible Server. |
+| NodeList |Ansible inventory | Optional|If not provided, pre-loaded |
+| |hosts file with | |(VNF) inventory hosts |
+| |VNF groups and | |file must exist in the |
+| |respective IP | |Ansible Server otherwise |
+| |addresses or DNS | |request fails. |
+| |supported FQDNs | | |
+| |that the playbook must| | |
+| |be executed against. | | |
+---------------+----------------------+---------+----------------------------+
| FileParameters| A JSON dictionary | Optional| Depends on the VNF action |
| | where keys are | | and playbook design. |
“Action”:”Configure”,
- "PlaybookName": "Ansible\_configure.yml",
+ "PlaybookName": "<VNFCode>/<Version>/ansible/configure/site.yml",
"NodeList": ["test1.vnf\_b.onap.com", “test2.vnf\_b.onap.com”],
a. Process the “FileParameters” dictionary and generate a file named
‘config.txt’ with contents set to the value of the ‘config.txt’ key.
-b. Execute the playbook named ‘Ansible\_configure.yml’ on nodes with
- FQDNs test1.vnf\_b.onap.com and test2.vnf\_b.onap.com respectively
- while providing the following key value pairs to the playbook:
+b. Execute the playbook named ‘<VNFCode>/<Version>/ansible/configure/site.yml’
+ on nodes with FQDNs test1.vnf\_b.onap.com and test2.vnf\_b.onap.com
+ respectively while providing the following key value pairs to the playbook:
Retry=3, Wait=5, ConfigFile=config.txt
+
c. If execution time of the playbook exceeds 60 secs (across all hosts),
it will be terminated.
| | | \\MainServiceTemplate.mf |
+------------+-------------------------------------+--------------------------+
+
Requirement List
--------------------------------
in multi-zoned cloud sites to allow for site support in the event of cloud
zone failure or upgrades.
+R-00098 The VNF **MUST NOT** impact the ability of the VNF to provide
+service/function due to a single container restart.
+
+R-79952 The VNF **SHOULD** support container snapshots if not for rebuild
+and evacuate for rollback or back out mechanism.
+
R-92935 The VNF **SHOULD** minimize the propagation of state information
across multiple data centers to avoid cross data center traffic.
R-36792 The VNF **MUST** automatically retry/resubmit failed requests
made by the software to its downstream system to increase the success rate.
+R-70013 The VNF **MUST NOT** require any manual steps to get it ready for
+service after a container rebuild.
+
+R-65515 The VNF **MUST** provide a mechanism and tool to start VNF
+containers (VMs) without impacting service or service quality assuming
+another VNF in same or other geographical location is processing service
+requests.
+
+R-94978 The VNF **MUST** provide a mechanism and tool to perform a graceful
+shutdown of all the containers (VMs) in the VNF without impacting service
+or service quality assuming another VNF in same or other geographical
+location can take over traffic and process service requests.
+
R-22059 The VNF **MUST NOT** execute long running tasks (e.g., IO,
database, network operations, service calls) in a critical section
of code, so as to minimize blocking of other operations and increase
Code Grant and Client Credentials Grant, as the standard interface
for a VNF.
-R-86455 The VNF **SHOULD** support hosting connectors for OS
-Level and Application Access.
-
R-48080 The VNF **SHOULD** support SCEP (Simple Certificate
Enrollment Protocol).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heat
-~~~~~~
+~~~~
-R-43125 The VNF Heat **MUST** indent properties and lists with 1 or
-more spaces.
+R-95303 A VNF's Heat Orchestration Template **MUST**
+be defined using valid YAML.
-R-67888 The VNF Heat **MUST** contain the following
-sections:
+R-27078 A VNF's Heat Orchestration template **MUST** contain
+the section "heat_template_version:".
-- heat\_template\_version:
-- description:
-- parameters:
-- resources:
+R-39402 A VNF's Heat Orchestration Template **MUST**
+contain the section "description:".
-R-39402 The VNF Heat **MUST** contain the description section.
+R-35414 A VNF Heat Orchestration's template **MUST**
+contain the section "parameters:".
-R-35414 The VNF Heat **MUST** contain the parameter section.
+R-90279 A VNF Heat Orchestration's template's parameter **MUST**
+be used in a resource with the exception of the parameters
+for the OS::Nova::Server resource property availability_zone.
-R-90279 The VNF Heat **MUST** use in a resource all parameters declared in
-a template except for the parameters for the OS::Nova::Server property
-availability\_zone. See Property: availability\_zone. for more details on
-availability\_zone.
+R-91273 A VNF Heat Orchestration’s template’s parameter for
+the OS::Nova::Server resource property availability_zone
+**MAY NOT** be used in any OS::Nova::Resource.
-R-28657 The VNF Heat **MUST** provide the attribute 'type' on
-parameters per the OpenStack Heat Orchestration Template standard.
+R-25877 A VNF's Heat Orchestration Template's parameter
+name (i.e., <param name>) **MUST** contain only
+alphanumeric characters and underscores ('_').
-R-44001 The VNF Heat **MUST** provide the attribute 'description'
-on parameters. (Note that this attribute is OpenStack optional.)
+R-36772 A VNF’s Heat Orchestration Template’s parameter
+**MUST** include the attribute “type:”.
-R-90526 The VNF Heat **MUST NOT** use the attribute 'default'.
-If a parameter has a default value, it must be provided in
-the environment file. (Note that this attribute is OpenStack
-optional.)
+R-11441 A VNF’s Heat Orchestration Template’s parameter
+type **MUST** be one of the following values: "string",
+"number", "json", "comma_delimited_list" or "boolean".
-R-88863 The VNF Heat **MUST** have a constraint of range or
-allowed\_values for a parameter type 'number'.
+R-32094 A VNF's Heat Orchestration Template parameter
+declaration **MAY** contain the attribute "label:"
-- range: The range constraint applies to parameters of type number.
- It defines a lower and upper limit for the numeric value of the
- parameter. The syntax of the range constraint is
+R-44001 A VNF's Heat Orchestration Template parameter
+declaration **MUST** contain the attribute "description".
-R-23664 The VNF Heat **MUST** have a resources: section with the
-declaration of at least one resource.
+R-90526 A VNF Heat Orchestration Template parameter
+declaration **MUST** not contain the default attribute.
-R-16447 The VNF Heat **MUST** have unique resource IDs across all Heat
-Orchestration Templates that compose the VNF. This requirement
-also applies when a VNF is composed of more than one Heat
-Orchestration Template (see ONAP VNF Modularity Overview).
+R-26124 If a VNF Heat Orchestration Template parameter
+requires a default value, it **MUST** be enumerated in the environment file.
-R-97199 The VNF Heat **MUST** use the metadata property for
-OS::Nova::Server resource type.
+R-32557 A VNF's Heat Orchestration Template parameter
+declaration MAY contain the attribute "hidden:".
-R-03324 The VNF Heat **MUST** contain the following sections in the
-environment file:
+R-88863 A VNF's Heat Orchestration Template's parameter defined as
+type "number" **MUST** have a parameter constraint of "range" or
+"allowed_values" defined.
-- parameters:
+R-40518 A VNF's Heat Orchestration Template’s parameter defined as
+type "string" **MAY** have a parameter constraint defined.
-R-19473 The VNF Heat **MUST** include “base” in the filename for the
-base module.
+R-96227 A VNF's Heat Orchestration Template’s parameter defined as
+type "json" **MAY** have a parameter constraint defined.
-R-81339 The VNF Heat **MUST** match one of the following options for
-the base module file name:
+R-79817 A VNF's Heat Orchestration Template’s parameter defined as
+type "comma_delimited_list" **MAY** have a parameter constraint defined.
-- base\_<text>.y[a]ml
-- <text>\_base.y[a]ml
-- base.y[a]ml
-- <text>\_base\_<text>.y[a]ml
+R-06613 A VNF's Heat Orchestration Template’s parameter defined as
+type "boolean" **MAY** have a parameter constraint defined.
-R-91342 The VNF Heat **MUST** name the base module’s corresponding
-environment file to be identical to the base module with “.y[a]ml”
-replaced with “.env”.
+R-00011 A VNF's Heat Orchestration Template's Nested YAML files
+parameter's **MUST NOT** have a parameter constraint defined.
-R-87247 The VNF Heat **MUST NOT** use any special characters or the
-word “base” in the name of the incremental module.
+R-22589 A VNF’s Heat Orchestration Template parameter declaration
+**MAY** contain the attribute "immutable:".
-- <text>.y[a]ml
+R-23664 A VNF's Heat Orchestration template **MUST** contain
+the section "resources:".
-R-94509 The VNF Heat **MUST** name the incremental module’s
-corresponding environment file to be identical to the incremental
-module with “.y[a]ml” replaced with “.env”.
+R-90152 A VNF's Heat Orchestration Template's "resources:"
+section **MUST** contain the declaration of at least one resource.
-R-82732 The VNF Heat **MUST** name the Cinder volume module file name
-to be the same as the corresponding module it is supporting (base
-module or incremental module) with “\_volume” appended.
+R-40551 A VNF's Heat Orchestration Template's Nested YAML files
+**MAY** contain the section "resources:".
-- <base module name>\_volume.y[a]ml
-- <incremental module name>\_volume.y[a]ml
+R-75141 A VNF's Heat Orchestration Template's resource name
+(i.e., <resource ID>) **MUST** only contain alphanumeric
+characters and underscores ('_').
-R-31141 The VNF Heat **MUST** name the volume module’s corresponding
-environment file to be identical to the volume module with “.y[a]ml”
-replaced with “.env”.
+R-16447 A VNF's <resource ID> **MUST** be unique across all
+Heat Orchestration Templates and all HEAT Orchestration Template
+Nested YAML files that are used to create the VNF.
-R-76057 The VNF Heat **MUST NOT** use special characters
-or the word “base” in the file name for the nested template.
+R-53952 A VNF’s Heat Orchestration Template’s Resource
+**MUST NOT** reference a HTTP-based resource definitions.
-R-18224 The VNF Heat **MUST** pass in as properties all parameter values
-associated with the nested heat file in the resource definition defined
-in the parent heat template.
+R-71699 A VNF’s Heat Orchestration Template’s Resource
+**MUST NOT** reference a HTTP-based Nested YAML file.
+
+R-10834 If a VNF Heat Orchestration Template resource attribute
+"property:" uses a nested "get_param", one level of nesting is
+supported and the nested "get_param" **MUST** reference an index
+
+R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server
+resource **MUST** contain the attribute "metadata".
-R-07443 The VNF Heat **MUST** match the Output parameter name and type with
-the input parameter name and type unless the Output parameter is of the
-type comma\_delimited\_list.
+R-46968 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “depends_on:”.
-R-23983 The VNF **MUST** pass the external networks into the VNF Heat
-Orchestration Templates as parameters.
+R-63137 VNF’s Heat Orchestration Template’s Resource **MAY**
+declare the attribute “update_policy:”.
-- Neutron Network-id (UUID)
-- Neutron Network subnet ID (UUID)
-- Contrail Network Fully Qualified Domain Name (FQDN)
+R-43740 A VNF’s Heat Orchestration Template’s Resource
+**MAY** declare the attribute “deletion_policy:”.
-R-63345 The VNF Heat **MUST** pass the appropriate external
-network IDs into nested VM templates when nested Heat is used.
+R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY**
+declare the attribute “external_id:”.
-R-35666 The VNF Heat **MUST** include the resource(s) to
-create the internal network. The internal network must be either a
-Neutron Network or a Contrail Network.
+R-36982 A VNF’s Heat Orchestration template **MAY** contain the
+“outputs:” section.
-R-86972 The VNF Heat **MUST** create internal networks in the Base
-Module, in the modular approach, with their resource IDs exposed as outputs
-(i.e., ONAP Base Module Output Parameters) for use by all incremental
-modules. If the Network resource ID is required in the base template,
-then a get\_resource must be used.
+R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
+environment file, even if no parameters are required to be enumerated.
-R-68936 The VNF Heat **SHOULD** assign a unique
-{network-role} in the context of the VNF, when the internal network is
-created. ONAP Resource ID and Parameter Naming Convention provides
-additional details.
+R-86285 The VNF Heat Orchestration Template **MUST** have a
+corresponding environment file, even if no parameters are required to be
+enumerated.
-R-01455 The VNF Heat **MUST** assign a VNF unique
-{vm-type} for each Virtual Machine type (i.e., OS::Nova::Server)
-instantiated in the VNF. While the {vm-type} must be unique to the VNF,
-it does not have to be globally unique across all VNFs that ONAP
-supports.
+R-03324 The VNF Heat Orchestration Template **MUST** contain the
+"parameters" section in the
+environment file
-R-82481 The VNF Heat **MUST** include {vm-type} as part of the parameter name
-for any parameter that is associated with a unique Virtual Machine type.
+R-68198 A VNF’s Heat Orchestration template’s Environment File’s
+“parameters:” section **MAY** enumerate parameters.
-R-66729 The VNF Heat **MUST** include {vm-type} as part of the resource ID
-for any resource ID that is associated with a unique Virtual Machine type in
-the VNF.
+R-59930 A VNF’s Heat Orchestration template’s Environment
+File’s **MAY** contain the “parameter_defaults:” section.
-R-32394 The VNF Heat **MUST** use the same case for {vm-type} for all
-parameter names in the VNF.
+R-46096 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “encrypted_parameters:” section.
-R-46839 The VNF Heat **MUST** use the same case for {vm-type} for all
-Resource IDs in the VNF.
+R-24893 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “event_sinks:” section.
-R-05008 The VNF Heat **MUST NOT** be prefixed with a common
-{vm-type} identifier for the six ONAP Metadata parameters.
-They are *vnf\_name*, *vnf\_id*, *vf\_module\_id*, *vf\_module\_name*,
-*vm\_role*. The ONAP Metadata parameters are described in
-Resource: OS::Nova::Server – Metadata Parameters.
+R-42685 A VNF’s Heat Orchestration template’s Environment File’s
+**MAY** contain the “parameter_merge_strategies:” section.
-R-15422 The VNF Heat **MUST NOT** be prefixed with a common {vm-type}
-identifier the parameter referring to the OS::Nova::Server property
-availability\_zone. availability\_zone is described in
-Property: ailability_zone.
+R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT**
+contain the “resource_registry:” section.
-R-21330 The VNF Heat **MUST** include the {network-role} as part of the
-parameter name for any parameter that is associated with an external network.
+R-69663 A VNF **MAY** be composed from one or more Heat Orchestration
+Templates, each of which represents a subset of the overall VNF.
-R-11168 The VNF Heat **MUST** include the {network-role} as part of the
-resource ID for any resource ID that is associated with an external network
-must.
+R-33132 A VNF’s Heat Orchestration Template **MAY** be 1.) Base Module
+Heat Orchestration Template (also referred to as a Base Module), 2.)
+Incremental Module Heat Orchestration Template (referred to as an Incremental
+Module), or 3.) a Cinder Volume Module Heat Orchestration Template
+(referred to as Cinder Volume Module).
-R-84322 The VNF Heat **MUST** include int\_{network-role} as part of the
-parameter name for any parameter that is associated with an internal network.
+R-13196 A VNF **MAY** be composed of zero to many Incremental Modules
-R-96983 The VNF Heat **MUST** include int\_{network-role} as part of the
-resource ID for any resource ID that is associated with an internal network.
+R-28980 A VNF’s incremental module **MAY** be used for initial VNF
+deployment only.
-R-58424 The VNF Heat **MUST** use the same case for {network-role} for
-all parameter names in the VNF.
+R-86926 A VNF’s incremental module **MAY** be used for scale out only.
-R-21511 The VNF Heat **MUST** use the same case for {network-role} for
-all Resource IDs in the VNF.
+R-91497 A VNF’s incremental module **MAY** be used for both deployment
+and scale out.
-R-59629 The VNF Heat **MUST** have unique resource IDs within the
-resources section of a Heat Orchestration Template. This is an
-OpenStack Requirement.
+R-68122 A VNF’s incremental module **MAY** be deployed more than once,
+either during initial VNF deployment and/or scale out.
-R-43319 The VNF Heat **MUST** have unique resource IDs
-across all modules that compose the VNF,
-when a VNF is composed of more than one Heat Orchestration Template
-(i.e., modules).
+R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume
+**MAY** be defined in a Base Module.
-R-54517 The VNF Heat **MUST** include {vm-type} in the resource ID
-when a resource is associated with a single {vm-type}.
+R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in an Incremental Module.
-R-96482 The VNF Heat **MUST** include {network-role} in the resource ID
-when a resource is associated with a single external network.
+R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
+**MAY** be defined in a Cinder Volume Module.
-R-98138 The VNF Heat **MUST** include int\_{network-role} in the resource ID
-when a resource is associated with a single internal network.
+R-11200 The VNF **MUST** keep the scope of a Cinder volume module,
+when it exists, to be 1:1 with the VNF Base Module or Incremental Module.
-R-82115 The VNF Heat **MUST** include both the {vm-type} and
-{network-role} in the resource ID,
-when a resource is associated with a single {vm-type} and a single
-external network.
+R-11200 The VNF **MUST** keep the scope of a Cinder volume module, when it
+exists, to be 1:1 with the VNF Base Module or Incremental Module
-- The {vm-type} must appear before the {network-role} and must be
- separated by an underscore (i.e., {vm-type}\_{network-role}).
-- Note that an {index} value may separate the {vm-type} and the
- {network-role}. An underscore will separate the three values (i.e.,
- {vm-type}\_{index}\_{network-role}).
+R-36582 A VNF’s Base Module **MAY** utilize nested heat.
+
+R-56721 A VNF’s Incremental Module **MAY** utilize nested heat.
+
+R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat.
+
+R-87485 A VNF’s Heat Orchestration Template’s file extension **MUST**
+be in the lower case format ‘.yaml’ or ‘.yml’.
+
+R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension
+**MUST** be in the lower case format ‘.yaml’ or ‘.yml’.
+
+R-74304 A VNF’s Heat Orchestration Template’s Environment file extension
+**MUST** be in the lower case format ‘.env’.
+
+R-81339 A VNF Heat Orchestration Template’s Base Module file name **MUST**
+include ‘base’ in the filename and **MUST** match one of the following four
+formats: 1.) ‘base_<text>.y[a]ml’, 2.) ‘<text>_base.y[a]ml’, 3.)
+‘base.y[a]ml’, or 4.) ‘<text>_base_<text>’.y[a]ml; where ‘base’ is case
+insensitive and where ‘<text>’ **MUST** contain only alphanumeric characters
+and underscores ‘_’ and **MUST NOT** contain the case insensitive word ‘base’.
+
+R-91342 A VNF Heat Orchestration Template’s Base Module’s Environment File
+**MUST** be named identical to the VNF Heat Orchestration Template’s Base
+Module with ‘.y[a]ml’ replaced with ‘.env’.
+
+R-87247 A VNF Heat Orchestration Template’s Incremental Module file name
+**MUST** contain only alphanumeric characters and underscores ‘_’ and
+**MUST NOT** contain the case insensitive word ‘base’.
+
+R-94509 A VNF Heat Orchestration Template’s Incremental Module’s Environment
+File **MUST** be named identical to the VNF Heat Orchestration Template’s
+Incremental Module with ‘.y[a]ml’ replaced with ‘.env’.
+
+R-82732 A VNF Heat Orchestration Template’s Cinder Volume Module **MUST** be
+named identical to the base or incremental module it is supporting with
+‘_volume appended’
+
+R-31141 A VNF Heat Orchestration Template’s Cinder Volume Module’s Environment
+File **MUST** be named identical to the VNF Heat Orchestration Template’s
+Cinder Volume Module with .y[a]ml replaced with ‘.env’.
+
+R-76057 A VNF Heat Orchestration Template’s Nested YAML file name **MUST**
+contain only alphanumeric characters and underscores ‘_’ and **MUST NOT**
+contain the case insensitive word ‘base’.
+
+R-18224 The VNF Heat Orchestration Template **MUST** pass in as properties
+all parameter values
+associated with the nested heat file in the resource definition defined
+in the parent heat template.
-R-82551 The VNF Heat **MUST** include both the {vm-type} and
-int\_{network-role} in the resource ID,
-when a resource is associated with a single {vm-type} and a single
-internal network.
+R-52753 VNF’s Heat Orchestration Template’s Base Module’s output parameter’s
+name and type **MUST** match the VNF’s Heat Orchestration Template’s
+incremental Module’s name and type unless the output parameter is of type
+‘comma_delimited_list’, then the corresponding input parameter **MUST**
+be declared as type ‘json’.
-- The {vm-type} must appear before the int\_{network-role} and must be
- separated by an underscore (i.e., {vm-type}\_int\_{network-role}).
-- Note that an {index} value may separate the {vm-type} and the
- int\_{network-role}. An underscore will separate the three values
- (i.e., {vm-type}\_{index}\_int\_{network-role}).
+R-22608 When a VNF’s Heat Orchestration Template’s Base Module’s output
+parameter is declared as an input parameter in an Incremental Module,
+the parameter attribute ‘constraints:’ **MUST NOT** be declared.
-R-69287 The VNF Heat **MUST** use only alphanumeric characters and “\_”
-underscores in the resource ID. Special characters must not be used.
+R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output
+Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in
+template, while other Output Parameters **MAY** be included.
-R-71152 The VNF Heat **MUST** declare as type: string the parameter
-for property image.
+R-07443 A VNF’s Heat Orchestration Templates’ Cinder Volume Module Output
+Parameter’s name and type **MUST** match the input parameter name and type
+in the corresponding Base Module or Incremental Module unless the Output
+Parameter is of the type ‘comma_delimited_list’, then the corresponding input
+parameter **MUST** be declared as type ‘json’.
-R-91125 The VNF Heat **MUST** enumerate the parameter for property
-image in the Heat Orchestration Template environment file.
+R-20547 When an ONAP Volume Module Output Parameter is declared as an input
+parameter in a base or an incremental module Heat Orchestration Template,
+parameter constraints **MUST NOT** be declared.
-R-57282 The VNF Heat **MUST** have a separate parameter for image for
-Each VM type (i.e., {vm-type}) even if more than one {vm-type} shares
-the same image. This provides maximum clarity and flexibility.
+R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to
+utilize the OpenStack ‘heat stack-update’ command for scaling
+(growth/de-growth).
-R-50436 The VNF Heat **MUST** declare the parameter property for
-flavor as type: string.
+R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template
+design to support scaling (growth/de-growth).
-R-69431 The VNF Heat **MUST** enumerate the parameter for property
-flavor in the Heat Orchestration Template environment file.
+R-59482 A VNF’s Heat Orchestration Template **MUST NOT** be VNF instance
+specific or Cloud site specific
-R-40499 The VNF Heat **MUST** have a separate parameter for flavor for each
-VM type (i.e., {vm-type}) even if more than one {vm-type} shares the same
-flavor. This provides maximum clarity and flexibility.
+R-56750 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.
-R-22838 The VNF Heat **MUST NOT** enumerate the parameter for property name
-in the environment file.
+R-01896 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.
-R-51430 The VNF Heat **MUST** declare the parameter for property name as
-type: string or type: comma\_delimited\_list
+R-16968 A VNF’s Heat Orchestration Templates **MUST NOT** include heat
+resources to create external networks.
-R-98450 The VNF Heat **MUST** name the parameter availability\_zone\_{index}
-in the Heat Orchestration Template.
+R-00606 A VNF **MAY** be connected to zero, one or more than one external
+networks.
-R-13561 The VNF Heat **MUST** start the {index} at zero.
+R-57424 A VNF’s port connected to an external network **MUST** connect the
+port to VMs in another VNF and/or an external gateway and/or external router.
-R-60204 The VNF Heat **MUST** increment the {index} by one.
+R-29865 A VNF’s port connected to an external network **MUST NOT** connect
+the port to VMs in the same VNF.
-R-36887 The VNF Heat **MUST NOT** include the {vm-type} in the parameter name.
+R-69014 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.
-R-17020 The VNF Heat **MUST** include the following three mandatory
-metadata parameters for an OS::Nova::Server resource:
+R-05201 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.
-- vnf\_id
-- vf\_module\_id
-- vnf\_name
+R-83015 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.
-R-55218 The VNF Heat **MUST NOT** have parameter constraints defined
-for the OS::Nova::Server metadata parameter vnf\_id.
+R-87096 A VNF **MAY** contain zero, one or more than one internal networks.
-R-20856 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server
-metadata parameter vnf\_id in environment file.
+R-35666 If a VNF has an internal network, the VNF Heat Orchestration
+Template **MUST** include the heat resources to create the internal network.
-R-98374 The VNF Heat **MUST NOT** have parameter constraints
-defined for the OS::Nova::Server metadata parameter vf\_module\_id.
+R-86972 A VNF **SHOULD** create the internal network in the VNF’s Heat
+Orchestration Template Base Module.
-R-72871 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server
-metadata parameter vf\_module\_id in environment file.
+R-52425 A VNF’s port connected to an internal network **MUST** connect
+the port to VMs in the same VNF.
-R-44318 The VNF Heat **MUST NOT** have parameter constraints defined
-for the OS::Nova::Server metadata parameter vnf\_name.
+R-46461 A VNF’s port connected to an internal network **MUST NOT** connect
+the port to VMs in another VNF and/or an external gateway and/or
+external router.
-R-36542 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server
-metadata parameter vnf\_name in the environment file.
+R-68936 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.
-R-72050 The VNF Heat **MUST** contain {network-role} in the parameter name
+R-32025 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.
-R-57576 The VNF Heat **MUST** contain int\_{network-role}
-in the parameter name.
+R-69874 A VNF’s ‘{network-role}’ assigned to an internal network **MUST**
+be different than the ‘{network-role}’ assigned to the VNF’s external
+networks.
-R-93272 The VNF Heat **MUST** adhere to the following parameter naming
-convention in the Heat Orchestration Template, when the parameter
-associated with the property network is referencing an “external” network:
+R-34726 If a VNF’s port is connected to an internal network and the port
+is created in the same Heat Orchestration Template as the internal network,
+then the port resource **MUST** use a ‘get_resource’ to obtain
+the network UUID.
-- {network-role}\_net\_id for the Neutron network ID
-- {network-role}\_net\_name for the network name in OpenStack
+R-22688 If a VNF’s port is connected to an internal network and the
+port is created in an Incremental Module and the internal network is created
+in the Base Module then the UUID of the internal network **MUST** be exposed
+as a parameter in the ‘outputs:’ section of the Base Module and the port
+resource **MUST** use a ‘get_param’ to obtain the network UUID.
-R-65373 The VNF Heat **MUST** adhere to the following parameter naming
-convention, when the parameter associated with the property network is
-referencing an “internal” network:
+R-01455 When a VNF's Heat Orchestration Template creates a
+Virtual Machine (i.e., 'OS::Nova::Server'),
+each 'class' of VMs **MUST** be assigned a VNF unique
+'{vm-type}'; where 'class' defines VMs that **MUST** have the following
+identical characteristics:
-- int\_{network-role}\_net\_id for the Neutron network ID
-- int\_{network-role}\_net\_name for the network name in OpenStack
+R-82481 A VNF's Heat Orchestration Template's Resource
+property parameter that is associated with a unique Virtual
+Machine type **MUST** include '{vm-type}' as part of the
+parameter name with two exceptions:
-R-47716 The VNF Heat **MUST** adhere to the following parameter naming
-convention for the property fixed\_ips and Map Property subnet\_id
-parameter, when the parameter is referencing a subnet of an
-“external” network.
+R-66729 A VNF’s Heat Orchestration Template’s Resource that is
+associated with a unique Virtual Machine type **MUST** include
+‘{vm-type}’ as part of the resource ID.
-- {network-role}\_subnet\_id if the subnet is an IPv4 subnet
-- {network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
+R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain
+only alphanumeric characters and/or underscores '_' and
+**MUST NOT** contain any of the following strings: '_int' or 'int\_'
+or '\_int\_'.
-R-20106 The VNF Heat **MUST** adhere to the following naming convention for
-the property fixed\_ips and Map Property subnet\_id parameter,
-when the parameter is referencing the subnet of an “internal” network:
+R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a
+substring of {network-role}.
-- int\_{network-role}\_subnet\_id if the subnet is an IPv4 subnet
-- int\_{network-role}\_v6\_subnet\_id if the subnet is an IPv6 subnet
+R-32394 A VNF’s Heat Orchestration Template’s use of ‘{vm-type}’
+in all Resource property parameter names **MUST** be the same case.
-R-41177 The VNF Heat **MUST** include {vm-type} and {network-role}
-in the parameter name, when a SDN-C IP assignment is made to a
-port connected to an external network.
+R-46839 A VNF’s Heat Orchestration Template’s use of
+‘{vm-type}’ in all Resource IDs **MUST** be the same case.
-R-84898 The VNF Heat **MUST** adhere to the following naming convention,
-when the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: comma\_delimited\_list:
+R-36687 A VNF’s Heat Orchestration Template’s ‘{vm-type}’ case in
+Resource property parameter names **SHOULD** match the case of
+‘{vm-type}’ in Resource IDs and vice versa.
-- {vm-type}\_{network-role}\_ips for IPv4 address
-- {vm-type}\_{network-role}\_v6\_ips for IPv6 address
+R-21330 A VNF’s Heat Orchestration Template’s Resource property parameter
+that is associated with external network **MUST** include the
+‘{network-role}’’ as part of the parameter name
-R-34960 The VNF Heat **MUST** adhere to the following
-naming convention,
-when the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: string:
+R-11168 A VNF's Heat Orchestration Template's Resource ID that is
+associated with an external network **MUST** include the
+'{network-role}' as part of the resource ID.
-- {vm-type}\_{network-role}\_ip\_{index} for an IPv4 address
-- {vm-type}\_{network-role}\_v6\_ip\_{index} for an IPv6 address
+R-84322 A VNF's Heat Orchestration Template's Resource property
+parameter that is associated with an internal network
+**MUST** include 'int\_{network-role}' as part of the parameter
+name, where 'int\_' is a hard coded string.
-R-62584 The VNF Heat **MUST** adhere to
-the following naming convention,
-when the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: comma\_delimited\_list:
+R-96983 A VNF's Heat Orchestration Template's Resource ID that is
+associated with an internal network **MUST** include
+'int\_{network-role}' as part of the Resource ID, where
+'int\_' is a hard coded string.
-- {vm-type}\_int\_{network-role}\_ips for IPv4 address
-- {vm-type}\_int\_{network-role}\_v6\_ips for IPv6 address
+R-26506 A VNF's Heat Orchestration Template's '{network-role}'
+**MUST** contain only alphanumeric characters and/or
+underscores '_' and **MUST NOT** contain any of the following
+strings: '_int' or 'int\_' or '\_int\_'.
-R-29256 The VNF Heat **MUST** must adhere to the following
-naming convention,
-when the parameter for property fixed\_ips and Map Property ip\_address
-is declared type: string:
+R-00977 A VNF’s Heat Orchestration Template’s ‘{network-role}’
+**MUST NOT** be a substring of ‘{vm-type}’.
-- {vm-type}\_int\_{network-role}\_ip\_{index} for an IPv4 address
-- {vm-type}\_int\_{network-role}\_v6\_ip\_{index} for an IPv6 address
+R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource property parameter names **MUST** be the same case
-R-61282 The VNF Heat **MUST**
+R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’
+in all Resource IDs **MUST** be the same case.
+
+R-86588 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.
+
+R-54517 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single ‘{vm-type}’, the Resource ID **MUST** contain the ‘{vm-type}’.
+
+R-96482 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single external network, the Resource ID MUST contain the text
+‘{network-role}’.
+
+R-98138 When a VNF’s Heat Orchestration Template’s resource is associated
+with a single internal network, the Resource ID MUST contain the text
+‘int\_{network-role}’.
+
+R-82115 When a VNF's Heat Orchestration Template's resource is associated
+with a single '{vm-type}' and a single external network, the Resource
+ID text **MUST** contain both the '{vm-type}' and the '{network-role}'
+
+- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST**
+ be separated by an underscore '_'
+
+ - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}'
+
+- note that an '{index}' value **MAY** separate the '{vm-type}' and the
+ '{network-role}' and when this occurs underscores **MUST** separate the
+ three values.
+
+R-82551 When a VNF's Heat Orchestration Template's resource is associated
+with a single '{vm-type}' and a single internal network, the Resource ID
+**MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and
+
+- the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and
+ **MUST** be separated by an underscore '_'
+
+ - (e.g., '{vm-type}\_int\_{network-role}',
+ '{vm-type}_{index}\_int\_{network-role}')
+
+- note that an '{index}' value **MAY** separate the '{vm-type}' and the
+ 'int\_{network-role}' and when this occurs underscores **MUST** separate
+ the three values.
+
+R-67793 When a VNF’s Heat Orchestration Template’s resource is associated
+with more than one ‘{vm-type}’ and/or more than one internal and/or
+external network, the Resource ID **MUST NOT** contain the ‘{vm-type}’
+and/or ‘{network-role}’/’int\_{network-role}’. It also should contain the
+term ‘shared’ and/or contain text that identifies the VNF
+
+R-27970 When a VNF’s Heat Orchestration Template’s resource is associated
+with more than one ‘{vm-type}’ and/or more than one internal and/or
+external network, the Resource ID **MAY** contain the term ‘shared’
+and/or **MAY** contain text that identifies the VNF.
+
+R-11690 When a VNF’s Heat Orchestration Template’s Resource ID contains
+an {index} value (e.g. multiple VMs of same {vm-type}), the ‘{index}’
+**MUST** start at zero and increment by one.
+
+R-71152 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as
+type: ‘string’.
+
+R-58670 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter name **MUST** follow the
+naming convention ‘{vm-type}_image_name’.
+
+R-91125 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘image’ parameter **MUST** be enumerated in
+the Heat Orchestration Template’s Environment File and a value **MUST** be
+assigned.
+
+R-57282 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’
+**MUST** have a unique parameter name for the ‘OS::Nova::Server’
+property ‘image’ even if more than one {vm-type} shares the same image.
+
+R-50436 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as
+type: ‘string’.
+
+R-45188 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter name **MUST** follow the
+naming convention ‘{vm-type}_flavor_name’.
+
+R-69431 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be enumerated in the
+Heat Orchestration Template’s Environment File and a value **MUST** be
+assigned.
+
+R-40499 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ **MUST**
+have a unique parameter name for the ‘OS::Nova::Server’ property
+‘flavor’ even if more than one {vm-type} shares the same flavor.
+
+R-51430 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter **MUST** be declared as
+either type ‘string’ or type ‘comma_delimited_list”.
+
+R-54171 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
+the parameter name **MUST** follow the naming convention
+‘{vm-type}\_name\_{index}’, where {index} is a numeric value that starts
+at zero and increments by one.
+
+R-40899 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’,
+a parameter **MUST** be declared for each ‘OS::Nova::Server’ resource
+associated with the ‘{vm-type}’.
+
+R-87817 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter is defined as a
+‘comma_delimited_list’, the parameter name **MUST** follow the naming
+convention ‘{vm-type}_names’.
+
+R-85800 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}’.
+
+R-22838 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘name’ parameter **MUST NOT** be enumerated
+in the Heat Orchestration Template’s Environment File.
+
+R-44271 The VNF's Heat Orchestration Template's Resource
+'OS::Nova::Server' property 'name' parameter value **SHOULD NOT**
+contain special characters since the Contrail GUI has a limitation
+displaying special characters.
+
+R-98450 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter name
+**MUST** follow the naming convention ‘availability\_zone\_{index}’
+where the ‘{index}’ **MUST** start at zero and increment by one.
+
+R-23311 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST**
+be declared as type: ‘string’.
+
+R-59568 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST NOT**
+be enumerated in the Heat Orchestration Template’s Environment File.
+
+R-01359 A VNF’s Heat Orchstration Template that contains an
+‘OS::Nova:Server’ Resource **MAY** define a parameter for the property
+‘availability_zone’ that is not utilized in any ‘OS::Nova::Server’
+resources in the Heat Orchestration Template.
+
+R-99798 A VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY**
+boot from a Cinder Volume.
+
+R-83706 When a VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., ‘OS::Nova::Server’ Resource) boots from an image, the
+‘OS::Nova::Server’ resource property ‘image’ **MUST** be used.
+
+R-69588 When a VNF’s Heat Orchestration Template’s Virtual Machine
+(i.e., ‘OS::Nova::Server’ Resource) boots from Cinder Volume, the
+‘OS::Nova::Server’ resource property ‘block_device_mapping’ or
+‘block_device_mapping_v2’ **MUST** be used.
+
+R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter ‘vnf_id’.
+
+R-07507 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST** be declared
+as type: ‘string’.
+
+R-55218 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST NOT** have
+parameter contraints defined.
+
+R-20856 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ **MUST NOT** be
+enumerated in the Heat Orchestration Template’s environment file.
+
+R-44491 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_id’ is passed into a
+Nested YAML file, the parameter name ‘vnf_id’ **MUST NOT** change.
+
+R-71493 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter
+‘vf\_module\_id’.
+
+R-82134 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST**
+be declared as type: ‘string’.
+
+R-98374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
+have parameter contraints defined.
+
+R-72871 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-86237 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf_module_id’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_id’
+**MUST NOT** change.
+
+R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MUST** contain the metadata map value parameter
+‘vnf_name’.
+
+R-62428 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST** be
+declared as type: ‘string’.
+
+R-44318 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST NOT** have
+parameter contraints defined.
+
+R-36542 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST NOT** be
+enumerated in the Heat Orchestration Template’s environment file.
+
+R-16576 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ is passed into a
+Nested YAML file, the parameter name ‘vnf_name’ **MUST NOT** change.
+
+R-68023 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘vf\_module\_name’.
+
+R-39067 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’ **MUST**
+be declared as type: ‘string’.
+
+R-15480 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’
+**MUST NOT** have parameter contraints defined.
+
+R-80374 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’
+**MUST NOT** be enumerated in the Heat Orchestration Template’s
+environment file.
+
+R-49177 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_name’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_name’
+**MUST NOT** change.
+
+R-85328 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MAY** contain the metadata map value parameter ‘vm_role’.
+
+R-95430 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ **MUST** be
+declared as type: ‘string’.
+
+R-67597 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ **MUST NOT** have
+parameter contraints defined.
+
+R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vnf_name’ **MUST** be
+either
+
+ - enumerated in the VNF’s Heat Orchestration
+ Template’s environment file.
+
+ - hard coded in the VNF’s Heat Orchestration
+ Template’s OS::Nova::Resource metadata property.
+
+R-86476 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ value **MUST only**
+contain alphanumeric characters and underscores ‘_’.
+
+R-70757 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vm_role’ is passed into a
+Nested YAML file, the parameter name ‘vm_role’ **MUST NOT** change.
+
+R-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **MAY** contain the metadata map value parameter
+‘vf\_module\_index’.
+
+R-54340 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST** be
+declared as type: ‘number’.
+
+R-09811 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
+have parameter contraints defined.
+
+R-37039 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-22441 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ is passed
+into a Nested YAML file, the parameter name ‘vf\_module\_index’
+**MUST NOT** change.
+
+R-55306 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** be
+used in a VNF’s Volume Template; it is not supported.
+
+R-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘workload_context’.
+
+R-74978 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST** be
+declared as type: ‘string’.
+
+R-34055 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST NOT**
+have parameter contraints defined.
+
+R-02691 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-75202 If a VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘workload_context’ is passed
+into a Nested YAML file, the parameter name ‘workload_context’
+**MUST NOT** change.
+
+R-88536 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource **SHOULD** contain the metadata map value parameter
+‘environment_context’.
+
+R-20308 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST**
+be declared as type: ‘string’.
+
+R-56183 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST NOT**
+have parameter contraints defined.
+
+R-13194 A VNF’s Heat Orchestration Template’s OS::Nova::Server
+Resource metadata map value parameter ‘environment_context’ **MUST NOT**
+be enumerated in the Heat Orchestration Template’s environment file.
+
+R-62954 If a VNF’s Heat Orchestration 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.
+
+R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘network’ parameter **MUST** be declared as type: ‘string’.
+
+R-62983 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an external
+network, the ‘network’ parameter name **MUST**
+
+- follow the naming convention ‘{network-role}_net_id’ if the Neutron
+ network UUID value is used to reference the network
+- follow the naming convention ‘{network-role}_net_name’ if the OpenStack
+ network name is used to reference the network.
+
+where ‘{network-role}’ is the network-role of the external network and
+a ‘get_param’ **MUST** be used as the intrinsic function.
+
+R-86182 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an internal
+network, and the internal network is created in a different
+Heat Orchestration Template than the ‘OS::Neutron::Port’, the
+‘network’ parameter name **MUST**
+
+- follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron
+ network UUID value is used to reference the network
+- follow the naming convention ‘int\_{network-role}_net_name’ if the
+ OpenStack network name in is used to reference the network.
+
+where ‘{network-role}’ is the network-role of the internal network
+and a ‘get_param’ **MUST** be used as the intrinsic function.
+
+R-93177 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and
+the internal network is created in the same Heat
+Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’
+parameter name **MUST** obtain the UUID of the internal network by using
+the intrinsic function ‘get_resource’ or ‘get_attr’ and referencing the
+Resource ID of the internal network.
+
+R-29872 The VNF’s Heat Orchestration Template’s Resource ‘OS::Nova::Server’
+property ‘network’ parameter **MUST NOT** be enumerated in the Heat
+Orchestration Template’s Environment File.
+
+R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST** be
+declared as either type ‘string’ or type ‘comma_delimited_list’.
+
+R-40971 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an
+IPv4 address is assigned using the property
+‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined
+as a string, the parameter name **MUST** follow the naming
+convention ‘{vm-type}_{network-role}\_ip\_{index}’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+- the value for {index} must start at zero (0) and increment by one
+
+R-39841 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter
+‘{vm-type}_{network-role}\_ip\_{index}’ **MUST NOT** be enumerated in the
+VNF’s Heat Orchestration Template’s Environment File.
+
+R-04697 When the VNF’s Heat Orchestration Template’s
+Resource ‘OS::Neutron::Port’ is attaching to an external
+network, and an IPv4 address is assigned using the property
+‘fixed_ips’ map property ‘ip_address’ and the parameter type
+is defined as a comma_delimited_list, the parameter name **MUST**
+follow the naming convention ‘{vm-type}_{network-role}_ips’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+
+R-98905 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’
+property ‘fixed_ips’ map property ‘ip_address’ parameter
+‘{vm-type}_{network-role}_ips’ **MUST NOT** be enumerated in the VNF’s
+Heat Orchestration Template’s Environment File.
+
+R-71577 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+- the value for {index} must start at zero (0) and increment by one
+
+R-87123 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration
+Template’s Environment File.
+
+R-23503 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}_{network-role}_v6_ips’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the external network
+
+R-93030 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}_{network-role}_v6_ips’ **MUST NOT** be enumerated in the
+VNF’s Heat Orchestration Template’s Environment File.
+
+R-78380 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+- the value for {index} must start at zero (0) and increment by one
+
+R-28795 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}\_ip\_{index}’ **MUST** be enumerated
+in the VNF’s Heat Orchestration Template’s Environment File.
+
+R-85235 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}\_int\_{network-role}_ips’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+
+R-90206 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}_int_ips’ **MUST** be enumerated in
+the VNF’s Heat Orchestration Template’s Environment File.
+
+R-27818 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address
+is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and
+the parameter type is defined as a string, the parameter name **MUST** follow
+the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+- the value for {index} must start at zero (0) and increment by one
+
+R-97201 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’
+**MUST** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
+
+R-29765 When the VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6
+address is assigned using the property ‘fixed_ips’ map property ‘ip_address’
+and the parameter type is defined as a comma_delimited_list, the parameter
+name **MUST** follow the naming convention
+‘{vm-type}\_int\_{network-role}_v6_ips’, where
+
+- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server
+- ‘{network-role}’ is the {network-role} of the internal network
+
+R-98569 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter ‘{vm-type}\_int\_{network-role}_v6_ips’ **MUST** be enumerated in
+the VNF’s Heat Orchestration Template’s Environment File.
+
+R-62590 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter associated with an external network, i.e.,
+
+- {vm-type}_{network-role}\_ip\_{index}
+- {vm-type}_{network-role}\_ip\_v6\_{index}
+- {vm-type}_{network-role}_ips
+- {vm-type}_{network-role}_v6_ips
+
+**MUST NOT** be enumerated in the Heat Orchestration Template’s
+Environment File. ONAP provides the IP address assignments at
+orchestration time.
+
+R-93496 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’
+parameter associated with an internal network, i.e.,
+
+- {vm-type}\_int\_{network-role}\_ip\_{index}
+- {vm-type}\_int\_{network-role}\_ip\_v6\_{index}
+- {vm-type}\_int\_{network-role}_ips
+- {vm-type}\_int\_{network-role}_v6_ips
+
+**MUST** be enumerated in the Heat Orchestration Template’s Environment
+File and IP addresses **MUST** be assigned.
+
+R-38236 The VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+‘subnet’/’subnet_id’ parameter **MUST** be declared type ‘string’.
+
+R-62802 When the VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv4
+address is being Cloud Assigned by OpenStack’s DHCP Service and the
+external network IPv4 subnet is to be specified using the property
+‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
+follow the naming convention ‘{network-role}_subnet_id’, where
+‘{network-role}’ is the network role of the network.
+
+R-83677 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘{network-role}_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
+
+R-15287 When the VNF’s Heat Orchestration Template’s resource
+‘OS::Neutron::Port’ is attaching to an external network, and an IPv6
+address is being Cloud Assigned by OpenStack’s DHCP Service and the
+external network IPv6 subnet is to be specified using the property
+‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST**
+follow the naming convention ‘{network-role}_subnet_v6_id’, where
+‘{network-role}’ is the network role of the network.
+
+R-80829 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘{network-role}_subnet_v6_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
+
+R-84123 When
+
+- the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’
+ in an Incremental Module is attaching to an internal network
+ that is created in the Base Module, AND
+- an IPv4 address is being Cloud Assigned by OpenStack’s DHCP Service AND
+- the internal network IPv4 subnet is to be specified using the
+ property ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
+
+the parameter **MUST** follow the naming convention
+‘int\_{network-role}_subnet_id’, where ‘{network-role}’ is the
+network role of the internal network
+
+- Note that the parameter **MUST** be defined as an ‘output’ parameter in
+ the base module.
+
+R-69634 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+subnet’/’subnet_id’ parameter ‘int\_{network-role}_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
+
+R-76160 When
+
+- the VNF’s Heat Orchestration Template’s resource
+ ‘OS::Neutron::Port’ in an Incremental Module is attaching to an
+ internal network that is created in the Base Module, AND
+- an IPv6 address is being Cloud Assigned by OpenStack’s DHCP Service AND
+- the internal network IPv6 subnet is to be specified using the property
+ ‘fixed_ips’ map property ‘subnet’/’subnet_id’,
+
+the parameter **MUST** follow the naming convention
+‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’
+is the network role of the internal network
+
+- Note that the parameter **MUST** be defined as an ‘output’ parameter in
+ the base module.
+
+R-22288 The VNF’s Heat Orchestration Template’s Resource
+‘OS::Neutron::Port’ property ‘fixed_ips’ map property
+‘subnet’/’subnet_id’ parameter ‘int\_{network-role}_v6_subnet_id’
+**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s
+Environment File.
+
+R-61282 The VNF Heat Orchestration Template **MUST**
adhere to the following naming convention for the property
allowed\_address\_pairs and Map Property ip\_address parameter,
when the parameter is referencing an “external” network:
-- {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
-- {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
+- {vm-type}\_{network-role}\_floating\_ip for an IPv4 address
-R-16805 The VNF Heat **MUST** adhere to the following naming convention
-for the property allowed\_address\_pairs and Map Property ip\_address
-parameter when the parameter is referencing an “internal” network.
+- {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address
-- {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address
-- {vm-type}\_int\_{network-role}\_floating\_v6\_ip for an IPv6 address
+R-16805 The VNF Heat Orchestration Template **MUST** adhere to the
+following naming convention for the property allowed\_address\_pairs
+and Map Property ip\_address parameter when the parameter is
+referencing an “internal” network.
-R-85734 The VNF Heat **MUST** use the intrinsic function str\_replace
-in conjunction with the ONAP supplied metadata parameter
-vnf\_name to generate a unique value,
+R-85734 The VNF Heat Orchestration Template **MUST** use the
+intrinsic function str\_replace in conjunction with the ONAP
+supplied metadata parameter vnf\_name to generate a unique value,
when the property name for a non OS::Nova::Server resources is defined
in a Heat Orchestration Template.
-R-47788 The VNF Heat **MUST** have a 1:1 scope of a cinder volume module,
-when it exists, with the Base Module or Incremental Module
+R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1
+scope of a cinder volume module, when it exists, with the Base
+Module or Incremental Module
-R-79531 The VNF Heat **MUST** define “outputs” in the volume
-template for each Cinder volume resource universally unique
-identifier (UUID) (i.e. ONAP Volume Template Output Parameters).
+R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding
+environment file, even if no parameters are required to be enumerated.
-R-86285 The VNF Heat **MUST** have a
+R-86285 The VNF Heat Orchestration Template **MUST** have a
corresponding environment file, even if no parameters are required to be
enumerated.
-R-67205 The VNF Heat **MUST** have a corresponding
+R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding
environment file for a Base Module.
-R-35727 The VNF Heat **MUST** have a
+R-35727 The VNF Heat Orchestration Template **MUST** have a
corresponding environment file for an Incremental module.
-R-22656 The VNF Heat **MUST** have a corresponding environment file
-for a Cinder Volume Module.
-
-R-89868 The VNF Heat **MUST** have unique file names within the scope
-of the VNF for a nested heat yaml file.
-
-R-52530 The VNF Heat **MUST NOT** use a directory hierarchy for
-nested templates. All templates must be in a single, flat directory
-(per VNF).
+R-22656 The VNF Heat Orchestration Template **MUST** have a
+corresponding environment file for a Cinder Volume Module.
-R-11041 The VNF Heat **MUST** have the resource calling the
-nested yaml file pass in as properties all parameters defined
-in nested yaml file.
+R-89868 The VNF Heat Orchestration Template **MUST** have unique
+file names within the scope of the VNF for a nested heat yaml file.
-R-61183 The VNF Heat **MUST NOT** change the parameter names, when
-OS::Nova::Server metadata parameters are past into a nested heat template.
+R-52530 The VNF Heat Orchestration Template **MUST NOT** use a
+directory hierarchy for nested templates. All templates must be
+in a single, flat directory (per VNF).
-R-76718 The VNF Heat **MUST** reference the get\_files targets in
-Heat templates by file name, and the corresponding files should be
-delivered to ONAP along with the Heat templates.
+R-76718 The VNF Heat Orchestration Template **MUST** reference the
+get\_files targets in Heat templates by file name, and the corresponding
+files should be delivered to ONAP along with the Heat templates.
R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval.
-R-62177 The VNF Heat **MUST** have unique file names for the included
-files within the scope of the VNF.
-
-R-87848 The VNF Heat **MUST** have all included files in a single, flat
-directory per VNF. ONAP does not support a directory hierarchy.
-
-- Included files may be used by all Modules within a given VNF.
-- get\_file directives may be used in both non-nested and nested
- templates
+R-62177 The VNF Heat Orchestration Template **MUST** have unique
+file names for the included files within the scope of the VNF.
**ONAP Management Requirements**
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-R-77707 The VNF provider **MUST** include a Manifest File that
-contains a list of all the components in the VNF package.
+R-77707 The xNF provider **MUST** include a Manifest File that
+contains a list of all the components in the xNF package.
R-66070 The xNF Package **MUST** include xNF Identification Data to
uniquely identify the resource for a given xNF provider. The identification
data must include: an identifier for the xNF, the name of the xNF as was
given by the xNF provider, xNF description, xNF provider, and version.
-R-69565 The xNF Package **MUST** include documentation describing
-xNF Management APIs. The document must include information and
-tools for:
+R-69565 The xNF Package **MUST** include documentation describing xNF
+Management APIs, which must include information and tools for ONAP to
+deploy and configure (initially and ongoing) the xNF application(s)
+(e.g., NETCONF APIs) which includes a description of configurable
+parameters for the xNF and whether the parameters can be configured
+after xNF instantiation.
-- ONAP to deploy and configure (initially and ongoing) the xNF
- application(s) (e.g., NETCONF APIs). Includes description of
- configurable parameters for the xNF and whether the parameters
- can be configured after xNF instantiation.
-- ONAP to monitor the health of the xNF (conditions that require
- healing and/or scaling responses). Includes a description of:
+R-00156 The xNF Package **MUST** include documentation describing xNF
+Management APIs, which must include information and tools for ONAP
+to monitor the health of the xNF (conditions that require healing
+and/or scaling responses).
-- Parameters that can be monitored for the xNF and event records
- (status, fault, flow, session, call, control plane, etc.) generated
- by the xNF after instantiation.
-- Runtime lifecycle events and related actions (e.g., control
- responses, tests) which can be performed for the xNF.
+R-00068 The xNF Package **MUST** include documentation which includes
+a description of parameters that can be monitored for the xNF and
+event records (status, fault, flow, session, call, control plane,
+etc.) generated by the xNF after instantiation.
+
+R-12678 The xNF Package **MUST** include documentation which includes a
+description of runtime lifecycle events and related actions (e.g.,
+control responses, tests) which can be performed for the xNF.
R-84366 The xNF Package **MUST** include documentation describing
xNF Functional APIs that are utilized to build network and
R-98617 The xNF provider **MUST** provide information regarding any
dependency (e.g., affinity, anti-affinity) with other xNFs and resources.
-R-89571 The xNF **MUST** support and provide artifacts for
-configuration management using at least one of the following
-technologies:
-
-- NETCONF/YANG
-- Chef
-- Ansible
+R-89571 The xNF **MUST** support and provide artifacts for configuration
+management using at least one of the following technologies;
+a) Netconf/YANG, b) Chef, or c) Ansible.
R-30278 The xNF provider **MUST** provide a Resource/Device YANG model
as a foundation for creating the YANG model for configuration. This will
R-18525 The xNF provider **MUST** provide a JSON file for each
supported action for the xNF. The JSON file must contain key value
pairs with all relevant values populated with sample data that illustrates
-its usage. The fields and their description are defined in Appendix A.
+its usage. The fields and their description are defined in Tables A1
+and A2 in the Appendix.
R-75608 The xNF provider **MUST** provide playbooks to be loaded
on the appropriate Ansible Server.
R-16777 The xNF provider **MUST** provide a JSON file for each
supported action for the xNF. The JSON file must contain key value
pairs with all relevant values populated with sample data that illustrates
-its usage. The fields and their description are defined in Appendix B.
+its usage. The fields and their description are defined in Table B1 in
+the Appendix.
R-46567 The xNF Package **MUST** include configuration scripts
for boot sequence and configuration.
are implemented in the xNF.
R-01556 The xNF Package **MUST** include documentation describing the
-fault, performance, capacity events/alarms and other event records that
-are made available by the xNF. The document must include:
-
-- A unique identification string for the specific xNF, a description
- of the problem that caused the error, and steps or procedures to
- perform Root Cause Analysis and resolve the issue.
-- All events, severity level (e.g., informational, warning, error)
- and descriptions including causes/fixes if applicable for the event.
-- All events (fault, measurement for xNF Scaling, Syslogs, State Change
- and Mobile Flow), that need to be collected at each VM, VNFC
- (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF.
+fault, performance, capacity events/alarms and other event records
+that are made available by the xNF.
+
+R-16875 The xNF Package **MUST** include documentation which must include
+a unique identification string for the specific xNF, a description of
+the problem that caused the error, and steps or procedures to perform
+Root Cause Analysis and resolve the issue.
+
+R-35960 The xNF Package **MUST** include documentation which must include
+all events, severity level (e.g., informational, warning, error) and
+descriptions including causes/fixes if applicable for the event.
+
+R-42018 The xNF Package **MUST** include documentation which must include
+all events (fault, measurement for xNF Scaling, Syslogs, State Change
+and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF.
R-27711 The xNF provider **MUST** provide an XML file that contains a
list of xNF error codes, descriptions of the error, and possible
R-01478 The xNF Package **MUST** include documentation describing all
parameters that are available to monitor the xNF after instantiation
-(includes all counters, OIDs, PM data, KPIs, etc.) that must be collected
-for reporting purposes. The documentation must include a list of:
-
-- Monitoring parameters/counters exposed for virtual resource
- management and xNF application management.
-- KPIs and metrics that need to be collected at each VM for capacity
- planning and performance management purposes.
-- The monitoring parameters must include latencies, success rates,
- retry rates, load and quality (e.g., DPM) for the key
- transactions/functions supported by the xNF and those that must
- be exercised by the xNF in order to perform its function.
-- For each KPI, provide lower and upper limits.
-- When relevant, provide a threshold crossing alert point for
- each KPI and describe the significance of the threshold crossing.
-- For each KPI, identify the suggested actions that need to be
- performed when a threshold crossing alert event is recorded.
-- Describe any requirements for the monitoring component of tools
- for Network Cloud automation and management to provide these records
- to components of the xNF.
-- When applicable, provide calculators needed to convert raw data
- into appropriate reporting artifacts.
+(includes all counters, OIDs, PM data, KPIs, etc.) that must be
+collected for reporting purposes.
+
+R-73560 The xNF Package **MUST** include documentation about monitoring
+parameters/counters exposed for virtual resource management and xNF
+application management.
+
+R-90632 The xNF Package **MUST** include documentation about KPIs and
+metrics that need to be collected at each VM for capacity planning
+and performance management purposes.
+
+R-86235 The xNF Package **MUST** include documentation about the monitoring
+parameters that must include latencies, success rates, retry rates, load
+and quality (e.g., DPM) for the key transactions/functions supported by
+the xNF and those that must be exercised by the xNF in order to perform
+its function.
+
+R-33904 The xNF Package **MUST** include documentation for each KPI, provide
+lower and upper limits.
+
+R-53598 The xNF Package **MUST** include documentation to, when relevant,
+provide a threshold crossing alert point for each KPI and describe the
+significance of the threshold crossing.
+
+R-69877 The xNF Package **MUST** include documentation for each KPI,
+identify the suggested actions that need to be performed when a
+threshold crossing alert event is recorded.
+
+R-22680 The xNF Package **MUST** include documentation that describes
+any requirements for the monitoring component of tools for Network
+Cloud automation and management to provide these records to components
+of the xNF.
+
+R-33694 The xNF Package **MUST** include documentation to when applicable,
+provide calculators needed to convert raw data into appropriate reporting
+artifacts.
R-56815 The xNF Package **MUST** include documentation describing
supported xNF scaling capabilities and capacity limits (e.g., number
applicable) for each interface.
R-97102 The VNF Package **MUST** include VM requirements via a Heat
-template that provides the necessary data for:
+template that provides the necessary data for VM specifications
+for all VNF components - for hypervisor, CPU, memory, storage.
+
+R-20204 The VNF Package **MUST** include VM requirements via a Heat
+template that provides the necessary data for network connections,
+interface connections, internal and external to VNF.
-- VM specifications for all VNF components - for hypervisor, CPU,
- memory, storage.
-- Network connections, interface connections, internal and external to VNF.
-- High availability redundancy model.
-- Scaling/growth VM specifications.
+R-44896 The VNF Package **MUST** include VM requirements via a Heat
+template that provides the necessary data for high availability
+redundancy model.
+
+R-55802 The VNF Package **MUST** include VM requirements via a Heat
+template that provides the necessary data for scaling/growth VM
+specifications.
R-26881 The xNF provider **MUST** provide the binaries and images
needed to instantiate the xNF (xNF and VNFC images).
-R-96634 The VNF provider **MUST** describe scaling capabilities
-to manage scaling characteristics of the VNF.
+R-96634 The xNF provider **MUST** describe scaling capabilities
+to manage scaling characteristics of the xNF.
R-43958 The xNF Package **MUST** include documentation describing
the tests that were conducted by the xNF providor and the test results.
onboarding the xNF into the ONAP environment and automating processes
for putting the licenses into use and managing the full lifecycle of
the licenses. The details of this license model are described in
-Appendix C. Note: License metadata support in ONAP is not currently
-available and planned for 1Q 2018.
+Tables C1 to C8 in the Appendix. Note: License metadata support in
+ONAP is not currently available and planned for 1Q 2018.
Configuration Management
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut**
command.
+R-11790 The VNF **MUST** support ONAP Controller’s
+**Restart (stop/start or reboot)** command.
+
+R-56218 The VNF **MUST** support ONAP Controller’s Migrate command that
+moves container (VM) from a live Physical Server / Compute Node to
+another live Physical Server / Compute Node.
+
+R-38001 The VNF MUST support ONAP Controller’s **Rebuild** command.
+
+R-76901 VNF MUST support a container rebuild mechanism based on existing
+image (e.g. Glance image in Openstack environment) or a snapshot.
+
R-41430 The xNF **MUST** support ONAP Controller’s **HealthCheck**
command.
R-59610 The xNF **MUST** implement the data model discovery and
download as defined in [RFC6022].
-R-87662 The xNF **SHOULD** implement the NETCONF Event Notifications
-[RFC5277].
-
R-93443 The xNF **MUST** define all data models in YANG [RFC6020],
and the mapping to NETCONF shall follow the rules defined in this RFC.
R-80898 The xNF **MUST** support heartbeat via a <get> with null filter.
-R-06617 The xNF **MUST** support get-schema (ietf-netconf-monitoring)
-to pull YANG model over session.
-
R-25238 The xNF PACKAGE **MUST** validated YANG code using the open
source pyang [3]_ program using the following commands:
R-63953 The xNF **MUST** have the echo command return a zero value
otherwise the validation has failed
-R-26508 The xNF **MUST** support NETCONF server that can be
-mounted on OpenDaylight (client) and perform the following operations:
-
-- Modify, update, change, rollback configurations using each
- configuration data element.
-- Query each state (non-configuration) data element.
-- Execute each YANG RPC.
-- Receive data through each notification statement.
+R-26508 The xNF **MUST** support a NETCONF server that can be mounted on
+OpenDaylight (client) and perform the operations of: modify, update,
+change, rollback configurations using each configuration data element,
+query each state (non-configuration) data element, execute each YANG
+RPC, and receive data through each notification statement.
R-28545 The xNF **MUST** conform its YANG model to RFC 6060,
“YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)”
-R-29967 The xNF **MUST** conform its YANG model to RFC 6022,
-“YANG module for NETCONF monitoring”.
-
R-22700 The xNF **MUST** conform its YANG model to RFC 6470,
“NETCONF Base Notifications”.
“A YANG Data Model for System Management”.
R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407,
-“A YANG Data Model for SNMP Configuration”.
+“A YANG Data Model for SNMP Configuration”, if Netconf used to
+configure SNMP engine.
R-33946 The xNF **MUST** conform to the NETCONF RFC 4741,
“NETCONF Configuration Protocol”.
R-47068 The xNF **MAY** expose a single endpoint that is
responsible for all functionality.
-R-67114 The xNF **MUST** be installed with:
-
-- Chef-Client >= 12.0
-- Chef push jobs client >= 2.0
+R-67114 The xNF **MUST** be installed with Chef-Client >= 12.0 and
+Chef push jobs client >= 2.0.
R-27310 The xNF Package **MUST** include all relevant Chef artifacts
(roles/cookbooks/recipes) required to execute xNF actions requested by
to ONAP upon completion of the chef-client run for any chef-client run
associated with a xNF action.
-- As part of the push job, ONAP will provide two parameters in the
- environment of the push job JSON object:
-
- - ‘RequestId’ a unique Id to be used to identify the request,
- - ‘CallbackUrl’, the URL to post response back.
-
-- If the CallbackUrl field is empty or missing in the push job, then
- the chef-client run need not post the results back via callback.
-
R-15885 The xNF **MUST** Upon completion of the chef-client run,
POST back on the callback URL, a JSON object as described in Table
A2 if the chef-client run list includes a cookbook/recipe that is
Ansible server for the endpoint VM(s) and comply with the Network
Cloud Service Provider guidelines for authentication and access.
-R-82018 The VNF **MUST** load the Ansible Server SSH public key onto VNF
+R-82018 The xNF **MUST** load the Ansible Server SSH public key onto xNF
VM(s) as part of instantiation. This will allow the Ansible Server
to authenticate to perform post-instantiation configuration without
-manual intervention and without requiring specific VNF login IDs and
-passwords.
+manual intervention and without requiring specific xNF login IDs
+and passwords.
-R-92866 The VNF **MUST** include as part of post-instantiation
-configuration done by Ansible Playbooks the removal/update of SSH
-public keys loaded through instantiation to support Ansible. This may
-include download and install of new SSH public keys.
+R-92866 The xNF **MUST** include as part of post-instantiation configuration
+done by Ansible Playbooks the removal/update of the SSH public key from
+/root/.ssh/authorized_keys, and update of SSH keys loaded through
+instantiation to support Ansible. This may include download and install of
+new SSH keys and new mechanized IDs.
-R-91745 The VNF **MUST** update the Ansible Server and other entities
+R-91745 The xNF **MUST** update the Ansible Server and other entities
storing and using the SSH keys for authentication when the SSH keys used
by Ansible are regenerated/updated.
R-40293 The xNF **MUST** make available playbooks that conform
to the ONAP requirement.
-R-49396 The xNF **MUST** support each ONAP (APPC) xNF action by
-invocation of **one** playbook [7]_. The playbook will be responsible
+R-49396 The xNF **MUST** support each ONAP (APPC) xNF action by invocation
+of **one** playbook [7]_. The playbook will be responsible
for executing all necessary tasks (as well as calling other playbooks)
to complete the request.
automatically ‘rollback’ to the original state in case of any errors
for actions that change state of the xNF (e.g., configure).
-R-58301 The VNF **SHOULD NOT** use playbooks that make requests to
+R-58301 The xNF **SHOULD NOT** use playbooks that make requests to
Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.);
therefore, there is no use for Cloud specific variables like Openstack
UUIDs in Ansible Playbooks.
-R-02651 The VNF **SHOULD** use the Ansible backup feature to save a
+R-02651 The xNF **SHOULD** use the Ansible backup feature to save a
copy of configuration files before implementing changes to support
operations such as backing out of software upgrades, configuration
changes or other work as this will help backing out of configuration
changes when needed.
-R-43353 The VNF **MUST** return control from Ansible Playbooks only
+R-43353 The xNF **MUST** return control from Ansible Playbooks only
after tasks are fully complete, signaling that the playbook completed
all tasks. When starting services, return control only after all services
are up. This is critical for workflows where the next steps are dependent
be encoded and serialized using `Avro <http://avro.apache.org/>`_,
where the Avro [6]_ data format are described using JSON.
+Note:
+
- JSON plain text format is preferred for moderate volume data sets
(option 1), as JSON has the advantage of having well-understood simple
processing and being human-readable without additional decoding. Examples
will read the schema when the stream is established and apply the
schema to the received content.
-R-98191 The xNF **MUST** vary the frequency that asynchronous data
-is delivered based on the content and how data may be aggregated or
-grouped together. For example, alarms and alerts are expected to be
-delivered as soon as they appear. In contrast, other content, such as
-performance measurements, KPIs or reported network signaling may have
-various ways of packaging and delivering content. Some content should
-be streamed immediately; or content may be monitored over a time interval,
-then packaged as collection of records and delivered as block; or data
-may be collected until a package of a certain size has been collected;
-or content may be summarized statistically over a time interval, or
-computed as a KPI, with the summary or KPI being delivered.
-
+R-98191 The xNF **MUST** vary the frequency that asynchronous data is
+delivered based on the content and how data may be aggregated or grouped
+together.
+
+Note:
+
+- For example, alarms and alerts are expected to be delivered as soon
+ as they appear. In contrast, other content, such as performance
+ measurements, KPIs or reported network signaling may have various ways
+ of packaging and delivering content. Some content should be streamed
+ immediately; or content may be monitored over a time interval, then packaged
+ as collection of records and delivered as block; or data may be collected
+ until a package of a certain size has been collected; or content may be
+ summarized statistically over a time interval, or computed as a KPI, with
+ the summary or KPI being delivered.
- We expect the reporting frequency to be configurable depending
on the virtual network function’s needs for management. For example,
Service Provider may choose to vary the frequency of collection between
promptly resolve connectivity problems caused by a collector or network
failure transparently to the xNF.
-R-81777 The VNF **MUST** be configured with initial address(es) to use
+R-81777 The xNF **MUST** be configured with initial address(es) to use
at deployment time. Subsequently, address(es) may be changed through
-ONAP-defined policies delivered from ONAP to the VNF using PUTs to a
+ONAP-defined policies delivered from ONAP to the xNF using PUTs to a
RESTful API, in the same manner that other controls over data reporting
will be controlled by policy.
-R-08312 The xNF **MAY** use other options which are expected to include
+R-08312 The xNF **MAY** use another option which is expected to include REST
+delivery of binary encoded data sets.
+
+R-79412 The xNF **MAY** use another option which is expected to include TCP
+for high volume streaming asynchronous data sets and for other high volume
+data sets. TCP delivery can be used for either JSON or binary encoded data
+sets.
+
+R-01033 The xNF **MAY** use another option which is expected to include SFTP
+for asynchronous bulk files, such as bulk files that contain large volumes of
+data collected over a long time interval or data collected across many xNFs.
+(Preferred is to reorganize the data into more frequent or more focused data
+sets, and deliver these by REST or TCP as appropriate.)
-- REST delivery of binary encoded data sets.
-- TCP for high volume streaming asynchronous data sets and for other
- high volume data sets. TCP delivery can be used for either
- JSON or binary encoded data sets.
-- SFTP for asynchronous bulk files, such as bulk files that contain
- large volumes of data collected over a long time interval or data
- collected across many xNFs. This is not preferred. Preferred is to
- reorganize the data into more frequent or more focused data sets, and
- deliver these by REST or TCP as appropriate.
-- REST for synchronous data, using RESTCONF (e.g., for xNF state polling).
+R-63229 The xNF **MAY** use another option which is expected to include REST
+for synchronous data, using RESTCONF (e.g., for xNF state polling).
R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses
as data destinations for each xNF, and may be changed by Policy while
R-34660 The xNF **MUST** use the RESTCONF/NETCONF framework used by
the ONAP configuration subsystem for synchronous communication.
-R-86586 The VNF **MUST** use the YANG configuration models and RESTCONF
+R-86586 The xNF **MUST** use the YANG configuration models and RESTCONF
[RFC8040] (https://tools.ietf.org/html/rfc8040).
R-11240 The xNF **MUST** respond with content encoded in JSON, as
Ansible Playbook Examples
-----------------------------------------------
-The following sections contain examples of Ansible playbook contents
+The following sections contain examples of Ansible playbooks
which follow the guidelines.
Guidelines for Playbooks to properly integrate with APPC
$ pwd
/storage/vfdb/V16.1/ansible/configure
- $ ansible-playbook -i ../inventory/vfdb9904v/hosts site.yml --extra-vars "vnf_instance=vfdb9904v"
+ $ ansible-playbook -i ../inventory/vfdb9904vhosts site.yml --extra-vars "vnf_instance=vfdb9904v"
+
+ NOTE: To preserve Ansible inventory/group_vars capability, that makes
+ group_vars contents global variables available to all playbooks, when they
+ reside in the inventory directory, guidelines are being updated to name the
+ VNF inventory hosts file as (a flat file) <VNFName>hosts, stored in the
+ inventory directory, not a subdirectory under inventory. In the above
+ example: vfdb9904vhosts (removed / VNF name and hosts vfdb9904/vhosts)
Example of corresponding APPC API Call from ONAP – Ansible Server
Specifications:
-An example POST for requesting execution of configure Playbook:
+An example of a curl request simulating a Rest API POST requesting execution
+of configure Playbook (using playbook relative path):
.. code-block:: none
- {"Id": "10", "PlaybookName":
- "/storage/vfdb/latest/ansible/configure/site.yml", "NodeList":
- ["vfdb9904v"], "Timeout": 60, "EnvParameters": {"Retry": 3, "Wait": 5},
- "LocalParameters": {"vfdb9904v": {"T_true": 10, "T_false": 5,
- "T_nfo": 5}}}
+ curl -u APIUser:APIPassword -H "Content-type:application/json" -X POST
+ -d '{"Id": "8412", "PlaybookName": "vfdb/V5.x.x/ansible/configure/site.yml",
+ "Timeout":"600", "EnvParameters": { "vnf_instance": "vfdb9904v" }}'
+ http://ansible.server.com:5000/Dispatch
+
+Rest API GET request to obtain response/results for prior request
+(same Id as POST request above):
+
+.. code-block:: none
+
+ curl -u APIUser:APIPassword -H 'Content-type: application/json' -X GET
+ 'http://ansible.server.com:5000/Dispatch/?Id=8412&Type=GetResult'
Comments:
track request down to completion and provide status to APPC when
requested.
-- Playbook Name provided in the request (full path in this case)
+- Playbook Name relative path provided in the request as PlaybookName
-- Playbook path (in this example provided as part of playbook name as
- full path) or, later in a separate variable, playbook root directory
- needs to be part of APPC template.
+- Ansible Server Rest API is aware of playbook’s root directory which may
+ vary from instance to instance or Ansible Server cluster to cluster.
Ansible Playbooks will use the VNF instance name (passed using
--extra-vars "vnf\_instance=vfdb9904v") to identify other default values
.. code-block:: none
- $ ansible-playbook -i ../inventory/vfdb9904v/hosts site.yml --extra-vars "vnf_instance=vfdb9904v"
+ $ ansible-playbook -i ../inventory/vfdb9904vhosts site.yml --extra-vars "vnf_instance=vfdb9904v"
-SSH key info (name/path), used to authenticate with the VNF VMs, is one
-of the attributes stored in the Ansible Server inventory hosts file for
-the VNF instance and later will be passed down by APPC, in the inventory
-hosts file, to the Ansible Server as part of the request. Here hosts
-file to run ansible-playbook listed in this example above (IP addresses
-were scrubbed):
+Each Ansible Server or cluster is assigned its own identification to be used
+to authenticate to VNF VMs using Ansible Server or cluster specific set of
+SSH keys that may be rotated regularly. Here hosts file, no longer referencing
+file with SSH key credentials, to run ansible-playbook listed in this example
+above (IP addresses were scrubbed):
.. code-block:: none
localhost ansible_connection=local
[oam]
- 1xx.2yy.zzz.109 ansible_ssh_private_key_file=/storage/.ssh/Kilo-SSH-Key.pem
- 1xx.2yy.zzz.110 ansible_ssh_private_key_file=/storage/.ssh/Kilo-SSH-Key.pem
+ 1xx.2yy.zzz.109
+ 1xx.2yy.zzz.110
[rdb]
- 1xx.2yy.zzz.105 ansible_ssh_private_key_file=/storage/.ssh/Kilo-SSH-Key.pem
- 1xx.2yy.zzz.106 ansible_ssh_private_key_file=/storage/.ssh/Kilo-SSH-Key.pem
+ 1xx.2yy.zzz.105
+ 1xx.2yy.zzz.106
NOTE: APPC requests to run Playbooks/Cookbooks are specific to a VNF,
but could be more limited to one VM or one type of VM by the request
via APPC which then invoke VNF level playbooks. Playbooks that impact
more than a single VNF are not the current focus of these guidelines.
-And here the scrubbed default arguments for this VNF instance:
+Since last release of these guidelines, based on recent learnings,
+moving VNF Type global variables under inventory/group_vars files, this
+way variables and respective values are available to all playbooks without
+being explicitly referenced though an include statement. Also creating
+templates that are VNF Type specific, but moving away from static files
+that are VNF instance specific, working to obtain VNF instance specific
+from other sources, inventory database, etc.
+
+And here the scrubbed default arguments for this VNF instance(originated
+from previously re-factored playbooks now being phased out):
.. code-block:: none
vnf_instance=vfdb9904v
$ more ../vars/vfdb9904v/default_args.yml
- vnf_provider_network_network: d69fea03-xxx-yyy-zzz-nnnnnnnnnnnn
- vnf_provider_network_subnet: a07f6a3d-xxxx-yyy-zzz-ssssssssssss
vm_config_oam_vnfc_name: vfdb9904vm001oam001
vm_config_oam_hostname: vfdb9904vm001
vm_config_oam_provider_ip_address: 1xx.2yy.zzz.109
Parameters like VNF names, VNFC names, OA&M IP addresses, after
February, 2018 ONAP release, will be extracted from A&AI by APPC and
then passed down to Ansible Server, as part of APPC request through REST
-API. In the meantime, these VNF instance specific required values, will
+API. In the meantime, VNF instance specific required values, will
be stored on VNF instance directory, default arguments file and will be
used as defaults. For parameterized playbooks attribute-value pairs
passed down by APPC to Ansible Server always take precedence over
$ pwd
/storage/vfdb/latest/ansible
+ Again, originated from previously re-factored playbooks now being phased out:
$ more vars/vfdb9904v/default_args.yml
type generic template, derived from ENV files in CSAR or other files,
with these default values stored on the Ansible Server, together with
the overriding parameters passed down from APPC, to create the VNF
-instance specific set of attribute-value pairs to be used for the run in
-YAML format. Here is an excerpt from such a file that should look
+instance specific set of attribute-value pairs to be used for the run, in
+INI format. Here is an excerpt from such a file that should look
somewhat similar to ENV files:
.. code-block:: none
$ more tmp/vfdb9904v/all.yml
deployment_prefix: vfdb9904v
- vm_config:
- oam1: { vnfc_name: vfdb9904vm001oam001, hostname: vfdb9904vm001, provider_ip_address: 1xx.2yy.zzz.109, private_ip_address: 192.168.10.107 }
- oam2: { vnfc_name: vfdb9904vm002oam001, hostname: vfdb9904vm002, provider_ip_address: 1xx.2yy.zzz.110, private_ip_address: 192.168.10.108 }
- rdb1: { vnfc_name: vfdb9904vm003rdb001, hostname: vfdb9904vm003, provider_ip_address: 1xx.2yy.zzz.105, private_ip_address: 192.168.10.109 }
- rdb2: { vnfc_name: vfdb9904vm004rdb001, hostname: vfdb9904vm004, provider_ip_address: 1xx.2yy.zzz.106, private_ip_address: 192.168.10.110 }
- rdb3: { vnfc_name: vfdb9904vm005rdb001, hostname: vfdb9904vm005, provider_ip_address: 1xx.2yy.zzz.xxx, private_ip_address: 192.168.10.111 }
- rdb4: { vnfc_name: vfdb9904vm006rdb001, hostname: vfdb9904vm006, provider_ip_address: 1xx.2yy.zzz.yyy, private_ip_address: 192.168.10.112 }
…
timezone: Etc/UTC
…
template_version: '2014-10-16'
stack_name: vfdb9904v
- key_name: ONAPkilo-keypair
c3dbtype: OAM
stackName: vfdb9904v
juno_base: true
Inventory hosts file: should be VNF instance specific.
-Default variables: should be VNF instance specific/
+Default variables: should be VNF instance specific.
NOTE: Some playbooks may rely on inventory directory contents to target
the collection of VNFs in the Services Platform supported through
Ansible.
Playbooks and paths to referenced files: Playbooks shall not use
-absolute paths for file include entries (variables or playbooks) or
+absolute paths in include or import entries (variables or playbooks) or
other types of references.
-For this to work properly when running playbooks, the directory where
-the playbook resides shall be the current directory.
+For this to work properly, when running playbooks, the directory where
+the main playbook resides shall be the current directory.
-Playbook includes use paths relative to the main playbook directory when
-necessary.
+Playbook imports, when used, shall use paths relative to the main
+playbook directory.
Root directory named ansible - Any files provided with playbooks,
-included or referenced by playbooks, shall reside under the ansible
+included, imported, or referenced by playbooks, shall reside under the ansible
playbooks (root) directory, containing all playbook subdirectories, or
below that ansible root directory, in other subdirectories to support
on-boarding and portability of VNF collection of playbooks and related
Example of inventory hosts file path, relative to ansible playbooks root
directory (playbooks\_dir): ansible/inventory/vnfx0001v/hosts
-Designing for a shared environment, concurrently running playbooks,
+**Designing for a shared environment, concurrently running multiple playbooks,
targeting multiple VNF instances – default argument variables for
-specific VNF instances:
+specific VNF instances:**
Files containing attribute name value pairs (variable name and default
values), referenced/included by playbooks – Files containing VNF
the default attribute value pairs contained in the defaults file, may be
passed down by APPC, to the Ansible Server, overriding these defaults:
-Following the same approach for inventory hosts files, files
-referenced/included by playbooks containing default values,
+VNF instance specific files
+referenced/included by playbooks, containing default values, example,
default\_args.yml, shall be stored under a directory with VNF instance
name on the path.
ansible/vars/<VNF\_instance\_name>/default\_args.yml
+Example of include statement:
+
+- include_vars: ../vars/{{ vnf_instance }}/default_args.yml
+
+Again, this was originated from previously re-factored playbooks, now being
+phased out, to move away from having to create VNF instance specific files
+with VNF instance default variables. Moving to extract these values from
+inventory databases and provide them to Ansible Server as part of the APPC
+request, but may be used in a transition from having everything stored in the
+Ansible Server to APPC extracting and providing VNF instance specific
+attribute-value pairs to the Ansible Server as part of the request.
+
Files containing attribute name value pairs (variable name and default
values), referenced/included by playbooks – created dynamically by
playbooks:
-Following the same approach for inventory hosts files, to avoid
+To avoid
overwrites or collisions of multiple concurrently running VNF instance
requests, files created dynamically by playbooks, based on VNF generic
templates, combined with default values and arguments passed down by
Files containing site specific (Openstack location non-instance
specific) attribute name value pairs, like NTP server and DNS server’s
IP addresses and other parameters, referenced/included by playbooks, not
-VNF specific – Could/should be stored under vars directory, in a
-subdirectory named after the string used to identify the site (nyc1,
+VNF specific – Could/should be stored under inventory/group_vars directory,
+in a subdirectory named after the string used to identify the site (nyc1,
lax2,…).
Examples:
-ansible/vars/<Site>/default\_args.yml
+ansible/inventory/group_vars/<Site>
+
+ansible/inventory/group_vars/nyc1
-ansible/vars/nyc1/default\_args.yml
+ansible/inventory/group_vars/lax2
-ansible/vars/lax2/default\_args.yml
\ **Ansible Server Design - Directory Structure**
**VNF type a.k.a VNF Function Code** - Based on current Services
Platform naming convention, each Virtual Network Function is assigned a
-4 character string (example vfdb), they are the first 4 characters on
-the VNF instance name, which is 9 characters long. VNF instance name in
+4 character string (example vfdb), these are 4 characters in
+the VNF instance name, followed by (4) numbers, ending in a "v", but the
+naming convention is evolving. VNF instance name in
some cases corresponds to the stack name for the VNF when VNF instance
is built based on a single module, single stack. Example of VNF instance
name: vfdb9904v. All VNF performing this function, running the same
-software, coming from the same VNF provider will start with the same 4
-characters, in this example, vfdb.
+software, coming from the same VNF provider will have the same 4
+characters in the VNF instance name, in this example, vfdb.
+
+NOTE: New naming convention includes a prefix indicating geographical
+location where VNF is instantiated.
VNF type, determined through these 4 characters, is also known as VNF
Function Code and is assigned by inventory team. All Services Platform
VNF Function Codes can be found in inventory database and/or A&AI as
well as Services Platform Network Design Documents.
-NOTE: Current Services Platform naming convention is undergoing changes
-to include geographical location to the VNF names.
-
Version – As in VNF software version is the release of the software
running on the VNF for which the playbooks were developed. VNF
configuration steps may change from release to release and this
<Version> in the path will allow the Ansible Server to host playbooks
associated with each software release. And run the playbooks that match
the software release running on each VNF instance. APPC initially will
-not support playbook versioning only latest playbook is supported.
+not support playbook versioning only latest playbook is supported or a hard
+coded version that later should become a variable to allow multiple
+actively in use playbook versions according to VNF release.
Playbook Function - Is a name associated with a life cycle management
task(s) performed by the playbook(s) stored in this directory. It should
clearly identify the type of action(s) performed by the main playbook
and possibly other playbooks stored in this same directory. Ideally,
-playbook function would match APPC corresponding function that executes
-the main playbook in this directory. Following Ansible Naming standards
-main playbook is usually named site.yml. There can be other playbooks on
-the same directory that use a subset of the roles used by the main
-playbook site.yml. Examples of Playbook Function directory names:
+playbook function would match APPC corresponding command or function that
+is performed by the main playbook in this directory. Following Ansible naming
+standards main playbook is usually named site.yml. There can be other
+playbooks on the same directory that use a subset of the roles used by the
+main playbook site.yml. Examples of Playbook Function directory names:
- configure – Contains post-instantiation (bulk) configuration
playbooks, roles,…
- healthcheck – Contains VNF health check playbook(s), roles,…
-- stop – Contains VNF application stop playbook(s), roles,…
+- stop – Contains VNF application stop (stopApplication) playbook(s),
+ roles,…
-- start – Contains VNF application start playbook(s), roles,…
+- start – Contains VNF application start (startApplication) playbook(s),
+ roles,…
Directory structure to allow hosting multiple version sets of playbooks,
for the same VNF type, to be hosted in the runtime environment on the
.. code-block:: none
-
/storage/<VNF type>/<Version>/ansible/<Playbook Function>/site.yml
+ <VNF type>/<Version>/ansible/<Playbook Function>/site.yml
Example – Post-instantiation (bulk) configuration –APPC Function -
Configure:
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/configure/site.yml
+ <VNF type>/<Version>/ansible/configure/site.yml
+
+Example – Post-instantiation (bulk) configuration –APPC Function
+– Configure – VNF software version 16.1:
+
+.. code-block:: none
+
+ vfdb/V16.1/ansible/configure/site.yml
Example – Health-check –APPC Function - HealthCheck:
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/healthcheck/site.yml
+ <VNF type>/<Version>/ansible/healthcheck/site.yml
OR (Function directory name does not need to match APPC function name)
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/check/site.yml
+ <VNF type>/<Version>/ansible/check/site.yml
Ansible Directories for other artifacts – VNF inventory hosts file -
Required:
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/inventory/<VNF instance name>/hosts
+ <VNF type>/<Version>/ansible/inventory/<VNF instance name>hosts
-Ansible Directories for other artifacts – VNF inventory hosts file –
-Required:
+Ansible Directories for other artifacts – VNF instance specific default
+arguments – Optional:
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/vars/<VNF instance name>/default\_args.yml
+ <VNF type>/<Version>/ansible/group_vars/<VNF instance name>
-NOTE: This requirement is expected to be deprecated in part in the
+NOTE: This requirement is expected to be deprecated all or in part in the
future, for automated actions, once APPC can pass down all VNF specific
arguments for each action. Requirement remains while manual actions are
to be supported. Other automated inventory management mechanisms may be
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/groups/<VNF instance name>/common\_groups.yml
+ <VNF type>/<Version>/ansible/inventory/group_vars/<VNF instance name>
NOTE: Default groups will be created based on VNFC type, 3 characters,
on VNFC name. Example: “oam”, “rdb”, “dbs”, “man”, “iox”, “app”,…
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/<Other directory(s)>
+ <VNF type>/<Version>/ansible/<Other directory(s)>
CAUTION: On referenced files used/required by playbooks.
- Any references to files, on includes or other playbook entries, shall
use relative paths.
-- This is the ansible (root directory) directory referenced on this
- note:
+- This is the ansible (root) directory referenced on this
+ note (Ansible Server mount point not included):
.. code-block:: none
- /storage/<VNF type>/<Version>/ansible/
+ <VNF type>/<Version>/ansible/
There will be a soft link to the latest set of Ansible Playbooks for
-each VNF type and this is the default set of playbooks that are executed
-unless a different release is specified in APPC request.
+each VNF type.
VNF type directories use A&AI inventory VNF function code. Ansible
Playbooks will be stored on a Cinder Volume mounted on the Ansible
section(s), playbooks need to be on-boarded onto Ansible Server(s). In
the future, they’ll be on-boarded and distributed through ONAP, at least
that is the proposed plan, but for now they need to be uploaded
-manually.
+manually. There is work in progress to use a Git as the playbook
+repository to store and track playbooks by version, version control.
These are the basic steps to on-board playbooks manually onto the
Ansible Server.
artifacts.
2. Create full directory (using –p option below) to store Ansible
- Playbooks and other artifacts under /storage file system.
+ Playbooks and other artifacts under /storage (or other configured)
+ file system.
a. Includes VNF type using VNF function code 4 characters under
/storage.
unzip …
bunzip ..
-5. Create directory for VNF (VMs) inventory hosts file with all VMs and
+5. Create VNF inventory hosts file with all VMs and
OA&M IP addresses for all VNF instances with known OA&M IP addresses
for respective VMs, example:
.. code-block:: none
- $ mkdir –p inventory/vfdb9904v
+ $ mkdir inventory
- $ touch inventory/vfdb9904v/hosts
+ $ touch inventory/vfdb9904vhosts
- $ cat inventory/vfdb9904v/hosts
+ $ cat inventory/vfdb9904vhosts
[host]
localhost ansible\_connection=local
[oam]
- 1xx.2yy.zzz.109 ansible\_ssh\_private\_key\_file=/storage/.ssh/Kilo-SSH-Key.pem
- 1xx.2yy.zzz.110 ansible\_ssh\_private\_key\_file=/storage/.ssh/Kilo-SSH-Key.pem
+ 1xx.2yy.zzz.109
+ 1xx.2yy.zzz.110
[rdb]
- 1xx.2yy.zzz.105 ansible\_ssh\_private\_key\_file=/storage/.ssh/Kilo-SSH-Key.pem
- 1xx.2yy.zzz.106 ansible\_ssh\_private\_key\_file=/storage/.ssh/Kilo-SSH-Key.pem
+ 1xx.2yy.zzz.105
+ 1xx.2yy.zzz.106
-6. Create directory to hold default arguments for each VNF instance,
- example:
+6. (Optional, being deprecated) Create directory to hold default
+arguments for each VNF instance,
+example:
.. code-block:: none
7. Perform some basic playbook validation running with “--check” option,
running dummy playbooks or other.
-8. Upload any SSH keys referenced on hosts file to appropriate
- directory.
+NOTE: Each Ansible Server or cluster of Ansible Server will have its own
+credentials to authenticate to VNF VMs. Ansible Server SSH public key(s)
+have to be loaded onto VNF VMs during instantiation or other way before
+Ansible Server can access VNF VMs and run playbooks. HOT templates used
+by heat to instantiate VNFs to be configured by these Ansible Servers running
+playbooks shall include the same SSH public key and load them onto VNF VM(s)
+as part of instantiation.
+
+Other non-vendor specific playbook tasks need to be incorporated in overall
+post-instantiation configuration playbook. Alternative is for company
+developed playbooks to be uploaded and executed, after VNF vendor provided
+playbooks are run.
+
+**A couple of playbooks used for proof-of-concept testing as examples:**
+
+UpgradePreCheck:
+
+.. code-block:: none
+
+ $ pwd
+ /storage/comx/V5.3.1.3/ansible/upgradeprecheck
+
+ $ more site.yml
+ ---
+
+ - import_playbook: ../common/create_vars.yml
+ - import_playbook: ../common/create_hosts.yml
+
+ - name: upgrade software pre check
+ hosts: oam,dbs,cpm
+ gather_facts: no
+ become: true
+ become_method: sudo
+ become_user: root
+ max_fail_percentage: 0
+ any_errors_fatal: True
+ roles:
+ - precheck
+ tags: precheck
+
+ $ more roles/precheck/tasks/main.yml
+ ---
+
+ - include_vars: /tmp/{{ vnf_instance }}/all.yml
+
+ - name: get software version installed on vnf
+ shell: grep "^SW_VERSION =" /vendor/software/config/param_common.cfg | grep -c "{{ existing_software_version }}"
+ register: version_line
+ ignore_errors: yes
+
+ - name: send msg when matches expected version
+ debug: msg="*** OK *** VNF software release matches (old) release to be upgraded."
+ verbosity=1
+ when: version_line.stdout.find('1') != -1
-NOTE: HOT templates used by Heat to instantiate VNF configured by these
-playbooks shall include the same SSH key to be installed as part of
-instantiation.
+ # send warning message and failure when release is not a match
+ - fail:
+ msg="*** WARNING *** VNF software release does not match expected (pre-upgrade) release."
+ when: (version_line | failed) or version_line.stdout.find('1') == -1
-Other non-VNF provider specific playbook tasks need to be incorporated on
-overall post-instantiation configuration playbooks or company Playbooks
-need to be uploaded and executed after VNF provided or internally
-developed playbooks for the VNF.
+
+UpgradePostCheck:
+
+.. code-block:: none
+
+ $ pwd
+ /storage/comx/V5.3.1.3/ansible/upgradepostcheck
+
+ $ more site.yml
+ ---
+
+ - import_playbook: ../common/create_vars.yml
+ - import_playbook: ../common/create_hosts.yml
+
+ - name: upgrade software post check
+ hosts: oam,dbs,cpm
+ gather_facts: no
+ become: true
+ become_method: sudo
+ become_user: root
+ max_fail_percentage: 0
+ any_errors_fatal: True
+ roles:
+ - postcheck
+ tags: postcheck
+
+ $ more roles/postcheck/tasks/main.yml
+ ---
+
+ - include_vars: /tmp/{{ vnf_instance }}/all.yml
+
+ - name: get post upgrade software version installed on vnf
+ shell: grep "^SW_VERSION =" /vendor/software/config/param_common.cfg | grep -c "{{ new_software_version }}"
+ register: version_line
+ ignore_errors: yes
+
+ - name: send msg when matches expected version
+ debug: msg="*** OK *** VNF software release matches new release."
+ verbosity=1
+ when: version_line.stdout.find('1') != -1
+
+ # send warning message and failure when release is not a match
+ - fail:
+ msg="*** WARNING *** VNF software release does not match expected new (post-upgrade) release."
+ when: (version_line | failed) or version_line.stdout.find('1') == -1
.. [1]
.. [7]
Multiple ONAP actions may map to one playbook.
+
+
Code Review / vnfrqts / requirements.git / blobdiff