NETCONF server supporting NETCONF APIs to comply with target ONAP and
industry standards.
-**Table 2. VNF Configuration via NETCONF**
-
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| **Principle** | **Description** | **Type** | **ID #** |
-+=================+=======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+============+============+
-| Configuration | Virtual Network functions (VNFs) must include a NETCONF server enabling runtime configuration and lifecycle management capabilities. The NETCONF server embedded in VNFs shall provide a NETCONF interface fully defined by supplied YANG models. | Must | 11010 |
-| | | | |
-| Management | | | |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| NETCONF | NETCONF server connection parameters shall be configurable during virtual machine instantiation through Heat templates where SSH keys, usernames, passwords, SSH service and SSH port numbers are Heat template parameters. | Must | 11020 |
-| | | | |
-| Server | | | |
-| | | | |
-| Requirements | | | |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Following protocol operations must be implemented: | Must | 11030 |
-| | | | |
-| | **close-session()**- Gracefully close the current session. | | |
-| | | | |
-| | **commit(confirmed, confirm-timeout)** - Commit candidate configuration datastore to the running configuration. | | |
-| | | | |
-| | **discard-changes()** - Revert the candidate configuration datastore to the running configuration | | |
-| | | | |
-| | **edit-config(target, default-operation, test-option, error-option, config)** - Edit the target configuration datastore by merging, replacing, creating, or deleting new config elements. | | |
-| | | | |
-| | **get(filter)** - Retrieve (a filtered subset of) the running configuration and device state information. This should include the list of VNF supported schemas. | | |
-| | | | |
-| | **get-config(source, filter)** - Retrieve a (filtered subset of a) configuration from the configuration datastore source. | | |
-| | | | |
-| | **kill-session(session)** - Force the termination of **session**. | | |
-| | | | |
-| | **lock(target)** - Lock the configuration datastore target. | | |
-| | | | |
-| | **unlock(target)** - Unlock the configuration datastore target. | | |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Following protocol operations should be implemented: | Should | 11040 |
-| | | | |
-| | **copy-config(target, source) -** Copy the content of the configuration datastore source to the configuration datastore target. | | |
-| | | | |
-| | **delete-config(target) -** Delete the named configuration datastore target. | | |
-| | | | |
-| | **get-schema(identifier, version, format) -** Retrieve the YANG schema. | | |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | All configuration data shall be editable through a NETCONF <*edit-config*> operation. Proprietary NETCONF RPCs that make configuration changes are not sufficient. | Must | 11050 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | By default, the entire configuration of the VNF must be retrievable via NETCONF's <get-config> and <edit-config>, independently of whether it was configured via NETCONF or other mechanisms. | Must | 11060 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The **:partial-lock** and **:partial-unlock** capabilities, defined in RFC 5717 must be supported. This allows multiple independent clients to each write to a different part of the <running> configuration at the same time. | Must | 11070 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The **:rollback-on-error** value for the <error-option> parameter to the <edit-config> operation must be supported. If any error occurs during the requested edit operation, then the target database (usually the running configuration) will be left affected. This provides an 'all-or-nothing' edit mode for a single <edit-config> request. | Must | 11080 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The server must support the **:startup** capability. It will allow the running configuration to be copied to this special database. It can also be locked and unlocked. | Must | 11090 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The **:url** value must be supported to specify protocol operation source and target parameters. The capability URI for this feature will indicate which schemes (e.g., file, https, sftp) that the server supports within a particular URL value. The 'file' scheme allows for editable local configuration databases. The other schemes allow for remote storage of configuration databases. | Must | 11100 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | At least one of the capabilities **:candidate** or **:writable-running** must be implemented. If both **:candidate** and **:writable-running** are provided then two locks should be supported. | Must | 11110 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The server must fully support the XPath 1.0 specification for filtered retrieval of configuration and other database contents. The 'type' attribute within the <filter> parameter for <get> and <get-config> operations may be set to 'xpath'. The 'select' attribute (which contains the XPath expression) will also be supported by the server. A server may support partial XPath retrieval filtering, but it cannot advertise the **:xpath** capability unless the entire XPath 1.0 specification is supported. | Must | 11120 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The **:validate** capability must be implemented. | Must | 11130 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | If **:candidate** is supported, **:confirmed-commit** must be implemented. | Must | 11140 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The **:with-defaults** capability [RFC6243] shall be implemented. | Must | 11150 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Data model discovery and download as defined in [RFC6022] shall be implemented. | Must | 11160 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | NETCONF Event Notifications [RFC5277] should be implemented. | Should | 11170 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | All data models shall be defined in YANG [RFC6020], and the mapping to NETCONF shall follow the rules defined in this RFC. | Must | 11180 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The data model upgrade rules defined in [RFC6020] section 10 should be followed. All deviations from section 10 rules shall be handled by a built-in automatic upgrade mechanism. | Must | 11190 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The VNF must support parallel and simultaneous configuration of separate objects within itself. | Must | 11200 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Locking is required if a common object is being manipulated by two simultaneous NETCONF configuration operations on the same VNF within the context of the same writable running data store (e.g., if an interface parameter is being configured then it should be locked out for configuration by a simultaneous configuration operation on that same interface parameter). | Must | 11210 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Locking must be applied based on the sequence of NETCONF operations, with the first configuration operation locking out all others until completed. | Must | 11220 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | If a VNF needs to lock an object for configuration, the lock must be permitted at the finest granularity to avoid blocking simultaneous configuration operations on unrelated objects (e.g., BGP configuration should not be locked out if an interface is being configured, Entire Interface configuration should not be locked out if a non-overlapping parameter on the interface is being configured). The granularity of the lock must be able to be specified via a restricted or full XPath expression. | Must | 11230 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | All simultaneous configuration operations should guarantee the VNF configuration integrity (e.g., if a change is attempted to the BUM filter rate from multiple interfaces on the same EVC, then they need to be sequenced in the VNF without locking either configuration method out). | Must | 11240 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | To prevent permanent lock-outs, locks must be released: | Must | 11250 |
-| | | | |
-| | a. when/if a session applying the lock is terminated (e.g., SSH session is terminated) | | |
-| | | | |
-| | b. when the corresponding <partial-unlock> operation succeeds | | |
-| | | | |
-| | c. when a user configured timer has expired forcing the NETCONF SSH Session termination (i.e., product must expose a configuration knob for a user setting of a lock expiration timer) | | |
-| | | | |
-| | Additionally, to guard against hung NETCONF sessions, another NETCONF session should be able to initiate the release of the lock by killing the session owning the lock, using the <kill-session> operation. | | |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The VNF should support simultaneous <commit> operations within the context of this locking requirements framework. | Must | 11260 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The supplied YANG code and associated NETCONF servers shall support all operations, administration and management (OAM) functions available from the supplier for VNFs. | Must | 11270 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Sub tree filtering must be supported. | Must | 11280 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Heartbeat via a <get> with null filter shall be supported. | Must | 11290 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Get-schema (ietf-netconf-monitoring) must be supported to pull YANG model over session. | Must | 11300 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The supplied YANG code shall be validated using the open source pyang [2]_ program using the following commands: | Must | 11310 |
-| | | | |
-| | $ pyang --verbose --strict <YANG-file-name(s)> | | |
-| | | | |
-| | $ echo $! | | |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The echo command must return a zero value otherwise the validation has failed. | Must | 11320 |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The supplier shall demonstrate mounting the NETCONF server on OpenDaylight (client) and: | Must | 11330 |
-| | | | |
-| | - 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. | | |
-+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-
-The following table provides the Yang models that suppliers must
+**VNF Configuration via NETCONF Requirements**
+
+**Configuration Management**
+
+* R-xxxxx The VNF **MUST** include a NETCONF server enabling runtime configuration and lifecycle management capabilities.
+* R-xxxxx The VNF **MUST** provide a NETCONF interface fully defined by supplied YANG models for the embedded NETCONF server.
+
+**NETCONF Server Requirements**
+
+* R-xxxxx The VNF **MUST** allow the NETCONF server connection parameters to be configurable during virtual machine instantiation through Heat templates where SSH keys, usernames, passwords, SSH service and SSH port numbers are Heat template parameters.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **close-session()**- Gracefully close the current session.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **commit(confirmed, confirm-timeout)** - Commit candidate configuration datastore to the running configuration.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **discard-changes()** - Revert the candidate configuration datastore to the running configuration.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **edit-config(target, default-operation, test-option, error-option, config)** - Edit the target configuration datastore by merging, replacing, creating, or deleting new config elements.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **get(filter)** - Retrieve (a filtered subset of) the running configuration and device state information. This should include the list of VNF supported schemas.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **get-config(source, filter)** - Retrieve a (filtered subset of a) configuration from the configuration datastore source.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **kill-session(session)** - Force the termination of **session**.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **lock(target)** - Lock the configuration datastore target.
+* R-xxxxx The VNF **MUST** implement the protocol operation: **unlock(target)** - Unlock the configuration datastore target.
+* R-xxxxx The VNF **SHOULD** implement the protocol operation: **copy-config(target, source) -** Copy the content of the configuration datastore source to the configuration datastore target.
+* R-xxxxx The VNF **SHOULD** implement the protocol operation: **delete-config(target) -** Delete the named configuration datastore target.
+* R-xxxxx The VNF **SHOULD** implement the protocol operation: **get-schema(identifier, version, format) -** Retrieve the YANG schema.
+* R-xxxxx The VNF **MUST** allow all configuration data shall to be edited through a NETCONF <edit-config> operation. Proprietary NETCONF RPCs that make configuration changes are not sufficient.
+* R-xxxxx The VNF **MUST** allow the entire configuration of the VNF to be retrieved via NETCONF's <get-config> and <edit-config>, independently of whether it was configured via NETCONF or other mechanisms.
+* R-xxxxx The VNF **MUST** support **:partial-lock** and **:partial-unlock** capabilities, defined in RFC 5717. This allows multiple independent clients to each write to a different part of the <running> configuration at the same time.
+* R-xxxxx The VNF **MUST** support **:rollback-on-error** value for the <error-option> parameter to the <edit-config> operation. If any error occurs during the requested edit operation, then the target database (usually the running configuration) will be left affected. This provides an 'all-or-nothing' edit mode for a single <edit-config> request.
+* R-xxxxx The VNF **MUST** support the **:startup** capability. It will allow the running configuration to be copied to this special database. It can also be locked and unlocked.
+* R-xxxxx The VNF **MUST** support the **:url** value to specify protocol operation source and target parameters. The capability URI for this feature will indicate which schemes (e.g., file, https, sftp) that the server supports within a particular URL value. The 'file' scheme allows for editable local configuration databases. The other schemes allow for remote storage of configuration databases.
+* R-xxxxx The VNF **MUST** implement at least one of the capabilities **:candidate** or **:writable-running**. If both **:candidate** and **:writable-running** are provided then two locks should be supported.
+* R-xxxxx The VNF **MUST** fully support the XPath 1.0 specification for filtered retrieval of configuration and other database contents. The 'type' attribute within the <filter> parameter for <get> and <get-config> operations may be set to 'xpath'. The 'select' attribute (which contains the XPath expression) will also be supported by the server. A server may support partial XPath retrieval filtering, but it cannot advertise the **:xpath** capability unless the entire XPath 1.0 specification is supported.
+* R-xxxxx The VNF **MUST** implement the **:validate** capability
+* R-xxxxx The VNF **MUST** implement **:confirmed-commit** If **:candidate** is supported.
+* R-xxxxx The VNF **MUST** implement the **:with-defaults** capability [RFC6243].
+* R-xxxxx The VNF **MUST** implement the data model discovery and download as defined in [RFC6022].
+* R-xxxxx The VNF **SHOULD** implement the NETCONF Event Notifications [RFC5277].
+* R-xxxxx The VNF **MUST** define all data models in YANG [RFC6020], and the mapping to NETCONF shall follow the rules defined in this RFC.
+* R-xxxxx The VNF **MUST** follow the data model upgrade rules defined in [RFC6020] section 10. All deviations from section 10 rules shall be handled by a built-in automatic upgrade mechanism.
+* R-xxxxx The VNF **MUST** support parallel and simultaneous configuration of separate objects within itself.
+* R-xxxxx The VNF **MUST** support locking if a common object is being manipulated by two simultaneous NETCONF configuration operations on the same VNF within the context of the same writable running data store (e.g., if an interface parameter is being configured then it should be locked out for configuration by a simultaneous configuration operation on that same interface parameter).
+* R-xxxxx The VNF **MUST** apply locking based on the sequence of NETCONF operations, with the first configuration operation locking out all others until completed.
+* R-xxxxx The VNF **MUST** permit locking at the finest granularity if a VNF needs to lock an object for configuration to avoid blocking simultaneous configuration operations on unrelated objects (e.g., BGP configuration should not be locked out if an interface is being configured or entire Interface configuration should not be locked out if a non-overlapping parameter on the interface is being configured).
+* R-xxxxx The VNF **MUST** be able to specify the granularity of the lock via a restricted or full XPath expression.
+* R-xxxxx The VNF **MUST** guarantee the VNF configuration integrity for all simultaneous configuration operations (e.g., if a change is attempted to the BUM filter rate from multiple interfaces on the same EVC, then they need to be sequenced in the VNF without locking either configuration method out).
+* R-xxxxx The VNF **MUST** release locks to prevent permanent lock-outs when/if a session applying the lock is terminated (e.g., SSH session is terminated).
+* R-xxxxx The VNF **MUST** release locks to prevent permanent lock-outs when the corresponding <partial-unlock> operation succeeds.
+* R-xxxxx The VNF **MUST** release locks to prevent permanent lock-outs when a user configured timer has expired forcing the NETCONF SSH Session termination (i.e., product must expose a configuration knob for a user setting of a lock expiration timer)
+* R-xxxxx The VNF **MUST** allow another NETCONF session to be able to initiate the release of the lock by killing the session owning the lock, using the <kill-session> operation to guard against hung NETCONF sessions.
+* R-xxxxx The VNF **MUST** support simultaneous <commit> operations within the context of this locking requirements framework.
+* R-xxxxx The VNF **MUST** support all operations, administration and management (OAM) functions available from the supplier for VNFs using the supplied YANG code and associated NETCONF servers.
+* R-xxxxx The VNF **MUST** support sub tree filtering.
+* R-xxxxx The VNF **MUST** support heartbeat via a <get> with null filter.
+* R-xxxxx The VNF **MUST** support get-schema (ietf-netconf-monitoring) to pull YANG model over session.
+* R-xxxxx The VNF PACKAGE **MUST** validated YANG code using the open source pyang [2]_ program using the following commands:
+
+.. code-block:: python
+
+ $ pyang --verbose --strict <YANG-file-name(s)>
+ $ echo $!
+
+* R-xxxxx The VNF **MUST** have the echo command return a zero value otherwise the validation has failed
+* R-xxxxx The VNF **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.
+
+
+
+The following requirements provides the Yang models that suppliers must
conform, and those where applicable, that suppliers need to use.
-Table 3. YANG Models
-
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| **RFC** | **Description** | **Type** | **ID #** |
-+================+====================================================================================+============+============+
-| RFC 6020 | YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) | Must | 12010 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 6022 | YANG module for NETCONF monitoring | Must | 12020 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 6470 | NETCONF Base Notifications | Must | 12030 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 6244 | An Architecture for Network Management Using NETCONF and YANG | Must | 12040 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 6087 | Guidelines for Authors and Reviewers of YANG Data Model Documents | Must | 12050 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| \*\*RFC 6991 | Common YANG Data Types | Should | 12060 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 6536 | NETCONF Access Control Model | Should | 12070 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 7223 | A YANG Data Model for Interface Management | Should | 12080 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 7224 | IANA Interface Type YANG Module | Should | 12090 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 7277 | A YANG Data Model for IP Management | Should | 12100 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 7317 | A YANG Data Model for System Management | Should | 12110 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
-| RFC 7407 | A YANG Data Model for SNMP Configuration | Should | 12120 |
-+----------------+------------------------------------------------------------------------------------+------------+------------+
+* R-xxxxx The VNF **MUST** conform its YANG model to RFC 6060, “YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)”
+* R-xxxxx The VNF **MUST** conform its YANG model to RFC 6022, “YANG module for NETCONF monitoring”.
+* R-xxxxx The VNF **MUST** conform its YANG model to RFC 6470, “NETCONF Base Notifications”.
+* R-xxxxx The VNF **MUST** conform its YANG model to RFC 6244, “An Architecture for Network Management Using NETCONF and YANG”.
+* R-xxxxx The VNF **MUST** conform its YANG model to RFC 6087, “Guidelines for Authors and Reviewers of YANG Data Model Documents”.
+* R-xxxxx The VNF **SHOULD** conform its YANG model to \*\*RFC 6991, “Common YANG Data Types”.
+* R-xxxxx The VNF **SHOULD** conform its YANG model to RFC 6536, “NETCONF Access Control Model”.
+* R-xxxxx The VNF **SHOULD** conform its YANG model to RFC 7223, “A YANG Data Model for Interface Management”.
+* R-xxxxx The VNF **SHOULD** conform its YANG model to RFC 7223, “IANA Interface Type YANG Module”.
+* R-xxxxx The VNF **SHOULD** conform its YANG model to RFC 7277, “A YANG Data Model for IP Management”.
+* R-xxxxx The VNF **SHOULD** conform its YANG model to RFC 7317, “A YANG Data Model for System Management”.
+* R-xxxxx The VNF **SHOULD** conform its YANG model to RFC 7407, “A YANG Data Model for SNMP Configuration”.
The NETCONF server interface shall fully conform to the following
NETCONF RFCs.
-Table 4. NETCONF RFCs
-
-+------------+--------------------------------------------------------------------+------------+------------+
-| **RFC** | **Description** | **Type** | **ID #** |
-+============+====================================================================+============+============+
-| RFC 4741 | NETCONF Configuration Protocol | Must | 12130 |
-+------------+--------------------------------------------------------------------+------------+------------+
-| RFC 4742 | Using the NETCONF Configuration Protocol over Secure Shell (SSH) | Must | 12140 |
-+------------+--------------------------------------------------------------------+------------+------------+
-| RFC 5277 | NETCONF Event Notification | Must | 12150 |
-+------------+--------------------------------------------------------------------+------------+------------+
-| RFC 5717 | Partial Lock Remote Procedure Call | Must | 12160 |
-+------------+--------------------------------------------------------------------+------------+------------+
-| RFC 6241 | NETCONF Configuration Protocol | Must | 12170 |
-+------------+--------------------------------------------------------------------+------------+------------+
-| RFC 6242 | Using the Network Configuration Protocol over Secure Shell | Must | 12180 |
-+------------+--------------------------------------------------------------------+------------+------------+
+* R-xxxxx The VNF **MUST** conform to the NETCONF RFC 4741, “NETCONF Configuration Protocol”.
+* R-xxxxx The VNF **MUST** conform to the NETCONF RFC 4742, “Using the NETCONF Configuration Protocol over Secure Shell (SSH)”.
+* R-xxxxx The VNF **MUST** conform to the NETCONF RFC 5277, “NETCONF Event Notification”.
+* R-xxxxx The VNF **MUST** conform to the NETCONF RFC 5717, “Partial Lock Remote Procedure Call”.
+* R-xxxxx The VNF **MUST** conform to the NETCONF RFC 6241, “NETCONF Configuration Protocol”.
+* R-xxxxx The VNF **MUST** conform to the NETCONF RFC 6242, “Using the Network Configuration Protocol over Secure Shell”.
VNF REST APIs
--------------
The port number, url, and other authentication information is provided
by the VNF vendor.
+**REST APIs**
+
+* R-xxxxx The VNF **MUST** support the HealthCheck RPC. The HealthCheck RPC, executes a vendor-defined VNF Healthcheck over the scope of the entire VNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. If the VNF is unable to run the HealthCheck, return a standard http error code and message.
+
+Examples:
+
+.. code-block:: python
+
+ 200
+ {
+ "identifier": "scope represented",
+ "state": "healthy",
+ "time": "01-01-1000:0000"
+ }
+
+ 200
+ {
+ "identifier": "scope represented",
+ "state": "unhealthy",
+ {[
+ "info": "System threshold exceeded details",
+ "fault":
+ {
+ "cpuOverall": 0.80,
+ "cpuThreshold": 0.45
+ }
+ ]},
+ "time": "01-01-1000:0000"
+ }
+
+
**Table 5. VNF REST APIs**
+-----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
| **Principal** | **Description** | **Type** | **ID #** |
+=================+=======================================================================================================================================================================================================================================================================================================================================================================================================+============+============+
-| REST APIs | The HealthCheck RPC, executes a vendor-defined VNF Healthcheck over the scope of the entire VNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. | Must | 12190 |
-| | | | |
-| | If the VNF is unable to run the HealthCheck, return a standard http error code and message. | | |
-| | | | |
-| | Examples: | | |
-| | | | |
-| | 200 | | |
-| | | | |
-| | { | | |
-| | | | |
-| | "identifier": "scope represented", | | |
-| | | | |
-| | "state": "healthy", | | |
-| | | | |
-| | "time": "01-01-1000:0000" | | |
-| | | | |
-| | } | | |
-| | | | |
-| | 200 | | |
-| | | | |
-| | { | | |
-| | | | |
-| | "identifier": "scope represented", | | |
-| | | | |
-| | "state": "unhealthy", | | |
-| | | | |
-| | {[ | | |
-| | | | |
-| | "info": "System threshold exceeded details", | | |
-| | | | |
-| | "fault": | | |
-| | | | |
-| | { | | |
-| | | | |
-| | "cpuOverall": 0.80, | | |
-| | | | |
-| | "cpuThreshold": 0.45 | | |
-| | | | |
-| | } | | |
-| | | | |
-| | ]}, | | |
-| | | | |
-| | "time": "01-01-1000:0000" | | |
-| | | | |
-| | } | | |
+-----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
| REST APIs | **/configuration** This API executes a vendor-defined VNF configuration action over the scope of the entire VNF(e.g if there are multiple VMs, then run configuration on all VMs according to the input parameters). | Must | 12200 |
| | **/configuration** returns a 201 Created if the configuration succeeds or a 4XX/5XX response if it fails. A JSON object is returned indicating the outcome of the VNF configuration including all the necessary configuration info. | | |
Chef-Client and Push Jobs Client on the VNF
(https://downloads.chef.io/).
-**Table 6. VNF Configuration via Chef**
-
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| **Principle** | **Description** | **Type** | **ID #** |
-+============================+===================================================================================================================================================================================================================================================================================================================================================+============+============+
-| Chef Server Requirements | ONAP will interact with the Chef Server designated to manage a target VNF. ONAP design allows for the VNF to register with the following types of Chef Server [3]_: | Must | 12310 |
-| | | | |
-| | - **Chef Server hosted by ONAP**: ONAP will provide a Chef Server to manage a VNF. If this choice is used then it is required that the VNF Vendor provide all relevant cookbooks to ONAP to be loaded on the Chef Server. | | |
-| | | | |
-| | - **Chef Server hosted in Tenant Space**: The Chef Server may also be hosted external to ONAP in tenant space. Same guidelines as ONAP Chef Server apply. In addition, the owner is required to provide appropriate credentials to ONAP in order to interact with the Chef Server. | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| Chef Client | It is required that as part of the installation process, the chef-client on the VNF be preloaded with validator keys and configuration to register with the designated Chef Server. | Must | 12320 |
-| | | | |
-| Requirements | | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | All the endpoints (VMs) of a VNF that contain chef-clients are required to have routable FQDNs which are used to register with the Chef Server. As part of invoking VNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a VNF, if required. | Must | 12330 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that each VNF expose a single endpoint that is responsible for all functionality. | May | 12331 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is required that the VNF be installed with | Must | 12340 |
-| | | | |
-| | - Chef-Client >= 12.0 | | |
-| | | | |
-| | - Chef push jobs client >= 2.0 | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| Chef Roles/ | Each VNF Vendor is required to make available for loading on appropriate Chef Server, all relevant Chef artifacts (roles/cookbooks/recipes) required to execute VNF actions requested by ONAP. | Must | 12350 |
-| | | | |
-| Requirements | | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | For each supported VNF action, the VNF Vendor is required to provide a run list of roles/cookbooks/recipes that will perform the desired VNF action in its entirety as specified by ONAP (see Section 8.c, ONAP Controller APIs and Behavior, for list of VNF actions and requirements), when triggered by a chef-client run list in JSON file. | Must | 12360 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | Roles/cookbooks/recipes invoked for a VNF action must not contain any instance specific parameters for the VNF. Instead they must accept all necessary instance specific data from the environment or node object attributes. | Must | 12370 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is required that all configurable parameters in the roles, cookbooks and recipes that can be set by ONAP, over-ride any default values. | Must | 12380 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is required that when executing a VNF action, if the chef-client run encounters any critical errors/failures, it update status on the Chef Server appropriately (e.g., via a fail or raise an exception). | Must | 12390 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | If the VNF action requires the output of a chef-client run be made available (e.g., get running configuration), an attribute, defined as node[‘PushJobOutput’] must be populated with the desired output on all nodes in the push job that execute chef-client run. | Must | 12400 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that, for actions that change state of the VNF (e.g., configure), the Vendor design appropriate cookbooks that can automatically ‘rollback’ to the original state in case of any errors. | Must | 12410 |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that any chef-client run associated with a VNF action support callback URLs to return information to ONAP upon completion of the chef-client run. | Should | 12420 |
-| | | | |
-| | - 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. | | |
-| | | | |
-| | - If the chef-client run list includes a cookbook/recipe that is callback capable, it is required to, upon completion of the chef-client run, POST back on the callback URL, a JSON object as described in Table A2. | | |
-| | | | |
-| | - Failure to POST on the Callback Url should not be considered a critical error. That is, if the chef-client successfully completes the VNF action, it should reflect this status on the Chef Server regardless of whether the Callback succeeded or not. | | |
-+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+**VNF Configuration via Chef Requirements**
+
+**Chef Server Requirements**
+
+ONAP will interact with the Chef Server designated to manage a target VNF. ONAP design allows for the VNF to register with the following types of Chef Server [3]_:
+
+- **Chef Server hosted by ONAP**: ONAP will provide a Chef Server to manage a VNF.
+
+ * R-xxxxx The VNF Package **MUST** include all relevant cookbooks to be loaded on the ONAP Chef Server.
+
+- **Chef Server hosted in Tenant Space**: The Chef Server may also be hosted external to ONAP in tenant space.
+
+ * R-xxxxx The VNF **MUST** meet the same guidelines as Chef Server hosted by ONAP.
+ * R-xxxxx The VNF Package **MUST** include appropriate credentials so that ONAP can interact with the Chef Server.
+
+**Chef Client Requirements**
+
+* R-xxxxx The VNF **MUST** have the chef-client be preloaded with validator keys and configuration to register with the designated Chef Server as part of the installation process.
+* R-xxxxx The VNF **MUST** have routable FQDNs for all the endpoints (VMs) of a VNF that contain chef-clients which are used to register with the Chef Server. As part of invoking VNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a VNF, if required.
+* R-xxxxx The VNF **MAY** expose a single endpoint that is responsible for all functionality.
+* R-xxxxx The VNF **MUST** be installed with:
+ - Chef-Client >= 12.0
+ - Chef push jobs client >= 2.0
+
+**Chef Roles/Requirements**
+
+* R-xxxxx The VNF Package **MUST** include all relevant Chef artifacts (roles/cookbooks/recipes) required to execute VNF actions requested by ONAP for loading on appropriate Chef Server.
+* R-xxxxx The VNF Package **MUST** include a run list of roles/cookbooks/recipes, for each supported VNF action, that will perform the desired VNF action in its entirety as specified by ONAP (see Section 8.c, ONAP Controller APIs and Behavior, for list of VNF actions and requirements), when triggered by a chef-client run list in JSON file.
+* R-xxxxx The VNF **MUST NOT** use any instance specific parameters for the VNF in roles/cookbooks/recipes invoked for a VNF action.
+* R-xxxxx The VNF **MUST** accept all necessary instance specific data from the environment or node object attributes for the VNF in roles/cookbooks/recipes invoked for a VNF action.
+* R-xxxxx The VNF **MUST** over-ride any default values for configurable parameters that can be set by ONAP in the roles, cookbooks and recipes.
+* R-xxxxx The VNF **MUST** update status on the Chef Server appropriately (e.g., via a fail or raise an exception) if the chef-client run encounters any critical errors/failures when executing a VNF action.
+* R-xxxxx The VNF **MUST** populate an attribute, defined as node[‘PushJobOutput’] with the desired output on all nodes in the push job that execute chef-client run if the VNF action requires the output of a chef-client run be made available (e.g., get running configuration).
+* R-xxxxx The VNF Package **MUST** have appropriate cookbooks that are designed to automatically ‘rollback’ to the original state in case of any errors for actions that change state of the VNF (e.g., configure).
+* R-xxxxx The VNF **SHOULD** support callback URLs to return information to ONAP upon completion of the chef-client run for any chef-client run associated with a VNF 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-xxxxx The VNF **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 callback capable. Failure to POST on the Callback Url should not be considered a critical error. That is, if the chef-client successfully completes the VNF action, it should reflect this status on the Chef Server regardless of whether the Callback succeeded or not.
ONAP Chef API Usage
~~~~~~~~~~~~~~~~~~~
framework of an Ansible Server that will host and invoke playbooks to
manage VNFs that support Ansible.
-**Table 7. VNF Configuration via Ansible**
-
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| **Principle** | **Description** | **Type** | **ID #** |
-+===============================+========================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================+============+============+
-| Ansible Server Requirements | ONAP will utilize an Ansible server in order to manage VNFs that support Ansible playbooks. We note that Ansible in general does not require the use of a server. However, this framework has been adopted to align with ONAP architecture, ease of management and scalability. | Must | 12510 |
-| | | | |
-| | All playbooks for the VNF will be hosted on a designated Ansible Server that meets ONAP Ansible API requirements. ONAP design allows for VNFs to be managed by an Ansible Server in any of the two following forms [5]_: | | |
-| | | | |
-| | - **Ansible Server hosted by ONAP**: ONAP will provide an Ansible Server to manage a VNF. If this choice is used then it is required that the VNF Vendor provide all relevant playbooks to ONAP to be loaded on the Ansible Server. | | |
-| | | | |
-| | - **Ansible Server hosted in Tenant Space**: Same guidelines as the ONAP Ansible Server. The Ansible Server must meet the ONAP Ansible Server API Interface requirements. | | |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| Ansible Client | The endpoints (VMs) of a VNF on which playbooks will be executed must have routable FQDNs that are reachable via the Ansible Server. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [6]_. | Must | 12520 |
-| | | | |
-| Requirements | | | |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that a VNF typically have a single endpoint. | May | 12521 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The endpoint VM(s) of a VNF on which an Ansible playbook will be executed is required to have Python >= 2.7. | Must | 12530 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The endpoint VM(s) must support SSH and allow SSH access to the Ansible server in line with Network Cloud Service Provider guidelines for authentication and access. | Must | 12540 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| Ansible Playbook | An Ansible playbook is a collection of tasks that is executed on the Ansible server (local host) and/or the target VM (s) in order to complete the desired action. Each VNF Vendor is required to make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirements. | Must | 12550 |
-| | | | |
-| Requirements | | | |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is required that each VNF action be supported 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. | Must | 12560 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | A playbook must not contain any instance specific parameters. It must utilize information from key value pairs that will be provided by the Ansible Server as extra-vars during invocation to execute the desired VNF action. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API. | Must | 12570 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | The Ansible Server will determine if a playbook invoked to execute a VNF action finished successfully or not using the “PLAY\_RECAP” summary in Ansible log. The playbook will be considered to successfully finish only if the “PLAY RECAP” section at the end of playbook execution output has no unreachable hosts and no failed tasks. Otherwise, the playbook will be considered to have failed. | Must | 12580 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | VNF vendor must design playbooks to allow Ansible Server to infer failure or success based on the “PLAY\_RECAP” capability. | Must | 12590 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | If, as part of a VNF action (e.g., audit), a playbook is required to return any VNF information, it must be written to a specific set of text files that will be retrieved and made available by the Ansible Server. The text files must be written in the same directory as the one from which the playbook is being executed. A text file must be created for each host the playbook is run on, with the name ‘<playbook name> <hostname>\_results.txt’ into which any desired output from each respective VM/VNF must be written. | Must | 12600 |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
-| | It is recommended that, for actions that change state of the VNF (e.g., configure), the VNF Vendor design appropriate playbooks that can automatically ‘rollback’ to the original state in case of any errors. | Should | 12610 |
-| | | | |
-| | NOTE: In case rollback at the playbook level is not supported or possible, vendor shall provide alternative locking mechanism (e.g., for a small VNF the rollback mechanism may rely on workflow to terminate and re-instantiate VNF VMs and then re-run playbook(s)). | | |
-+-------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
+**VNF Configuration via Ansible Requirements**
+
+**Ansible Server Requirements**
+
+ONAP will utilize an Ansible server in order to manage VNFs that support Ansible playbooks. We note that Ansible in general does not require the use of a server. However, this framework has been adopted to align with ONAP architecture, ease of management and scalability.
+All playbooks for the VNF will be hosted on a designated Ansible Server that meets ONAP Ansible API requirements. ONAP design allows for VNFs to be managed by an Ansible Server in any of the two following forms [5]_:
+
+- **Ansible Server hosted by ONAP**: ONAP will provide an Ansible Server to manage a VNF.
+
+ * R-xxxxx The VNF Package **MUST** include all relevant playbooks to ONAP to be loaded on the Ansible Server.
+
+- **Ansible Server hosted in Tenant Space**:
+
+ * R-xxxxx The VNF **MUST** meet the same guidelines as the Ansible Server hosted by ONAP.
+ * R-xxxxx The VNF **MUST** meet the ONAP Ansible Server API Interface requirements.
+
+**Ansible Client Requirements**
+
+* R-xxxxx The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [6]_.
+* R-xxxxx The VNF **MAY** have a single endpoint.
+* R-xxxxx The VNF **MUST** have Python >= 2.7 on the endpoint VM(s) of a VNF on which an Ansible playbook will be executed.
+* R-xxxxx The VNF **MUST** must support SSH and allow SSH access to the Ansible server for the endpoint VM(s) and comply with the Network Cloud Service Provider guidelines for authentication and access.
+
+**Ansible Playbook Requirements**
+
+An Ansible playbook is a collection of tasks that is executed on the Ansible server (local host) and/or the target VM (s) in order to complete the desired action.
+
+* R-xxxxx The VNF **MUST** make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirement.
+* R-xxxxx The VNF **MUST** support each VNF 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.
+* R-xxxxx The VNF **MUST NOT** use any instance specific parameters in a playbook.
+* R-xxxxx The VNF **MUST** utilize information from key value pairs that will be provided by the Ansible Server as extra-vars during invocation to execute the desired VNF action. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API.
+The Ansible Server will determine if a playbook invoked to execute a VNF action finished successfully or not using the “PLAY_RECAP” summary in Ansible log. The playbook will be considered to successfully finish only if the “PLAY RECAP” section at the end of playbook execution output has no unreachable hosts and no failed tasks. Otherwise, the playbook will be considered to have failed.
+
+* R-xxxxx The VNF **MUST** use playbooks designed to allow Ansible Server to infer failure or success based on the “PLAY_RECAP” capability.
+* R-xxxxx The VNF **MUST** write to a specific set of text files that will be retrieved and made available by the Ansible Server If, as part of a VNF action (e.g., audit), a playbook is required to return any VNF information.
+* R-xxxxx The VNF **SHOULD** use playbooks that are designed to automatically ‘rollback’ to the original state in case of any errors for actions that change state of the VNF (e.g., configure).
ONAP Controller APIs and Behavior
---------------------------------
Code Review / vnfrqts / requirements.git / commitdiff