diff options
Diffstat (limited to 'docs/Chapter7.rst')
| -rw-r--r-- | docs/Chapter7.rst | 62 |
1 files changed, 10 insertions, 52 deletions
diff --git a/docs/Chapter7.rst b/docs/Chapter7.rst index 5128978..943d7df 100644 --- a/docs/Chapter7.rst +++ b/docs/Chapter7.rst @@ -181,7 +181,7 @@ industry standards. * R-62468 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-01382 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-28756 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-83873 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-83873 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 unaffected. This provides an 'all-or-nothing' edit mode for a single <edit-config> request. * R-68990 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-68200 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-20353 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. @@ -328,19 +328,6 @@ Chef-Client and Push Jobs Client on the VNF **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 [2]_: - -- **Chef Server hosted by ONAP**: ONAP will provide a Chef Server to manage a VNF. - - * R-77786 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-85428 The VNF **MUST** meet the same guidelines as Chef Server hosted by ONAP. - * R-23823 The VNF Package **MUST** include appropriate credentials so that ONAP can interact with the Chef Server. - **Chef Client Requirements** * R-79224 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. @@ -390,7 +377,7 @@ action request against a Chef managed VNF. 3. Next, it creates a Node Object from the “Node” JSON dictionary for all elements listed in the NodeList (using the FQDN to construct the - endpoint) by replicating it [3]_. As part of this process, it will + endpoint) by replicating it [2]_. As part of this process, it will set the name field in each Node Object to the corresponding FQDN. These node objects are then posted on the Chef Server to corresponding Node Object REST endpoints to update the corresponding @@ -445,23 +432,9 @@ manage VNFs that support Ansible. **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 [4]_: - -- **Ansible Server hosted by ONAP**: ONAP will provide an Ansible Server to manage a VNF. - - * R-07879 The VNF Package **MUST** include all relevant playbooks to ONAP to be loaded on the Ansible Server. - -- **Ansible Server hosted in Tenant Space**: - - * R-35305 The VNF **MUST** meet the same guidelines as the Ansible Server hosted by ONAP. - * R-91681 The VNF **MUST** meet the ONAP Ansible Server API Interface requirements. - **Ansible Client Requirements** -* R-32217 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 [5]_. +* R-32217 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 [3]_. * R-98929 The VNF **MAY** have a single endpoint. * R-54373 The VNF **MUST** have Python >= 2.7 on the endpoint VM(s) of a VNF on which an Ansible playbook will be executed. * R-35401 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. @@ -471,7 +444,7 @@ All playbooks for the VNF will be hosted on a designated Ansible Server that mee 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-40293 The VNF **MUST** make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirement. -* R-49396 The VNF **MUST** support each VNF action by invocation of **one** playbook [6]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request. +* R-49396 The VNF **MUST** support each VNF action by invocation of **one** playbook [4]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request. * R-33280 The VNF **MUST NOT** use any instance specific parameters in a playbook. * R-48698 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. @@ -658,7 +631,7 @@ Monitoring & Management Requirements **Encoding and Serialization** -* R-19624 The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [7]_. +* R-19624 The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [5]_. - 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 of moderate volume data sets include the fault alarms and performance alerts, heartbeat messages, measurements used for VNF scaling and syslogs. - Binary format using Avro is preferred for high volume data sets (option 2) such as mobility flow measurements and other high-volume streaming events (such as mobility signaling events or SIP signaling) or bulk data, as this will significantly reduce the volume of data to be transmitted. As of the date of this document, all events are reported using plain text JSON and REST. @@ -716,7 +689,7 @@ runtime lifecycle. This data model is referred to as the VNF Event Streaming (VES) specifications. While this document is focused on specifying some of the records from the ONAP perspective, there may be other external bodies using the same framework to specify additional -records. For example, OPNFV has a VES project [8]_ that is looking to +records. For example, OPNFV has a VES project [6]_ that is looking to specify records for OpenStack’s internal telemetry to manage Application (VNFs), physical and virtual infrastructure (compute, storage, network devices), and virtual infrastructure managers (cloud controllers, SDN @@ -890,36 +863,21 @@ Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interf https://github.com/mbj4668/pyang .. [2] - Decision on which Chef Server instance associates with a VNF will be - made on a case-by-case basis depending on VNF, access requirements, - etc. and are outside the scope of this document. The specific - criteria for this would involve considerations like connectivity and - access required by the VNF, security, VNF topology and proprietary - cookbooks. - -.. [3] Recall that the Node Object **is required** to be identical across all VMs of a VNF invoked as part of the action except for the “name”. -.. [4] - Decision on which Ansible Server to use may happen on a case-by-case - basis depending on VNF, access requirements etc. and are outside the - scope of this document. The specific criteria for this could involve - considerations like connectivity and access required by the VNF, - security, VNF topology and proprietary playbooks. - -.. [5] +.. [3] Upstream elements must provide the appropriate FQDN in the request to ONAP for the desired action. -.. [6] +.. [4] Multiple ONAP actions may map to one playbook. -.. [7] +.. [5] This option is not currently supported in ONAP and it is currently under consideration. -.. [8] +.. [6] https://wiki.opnfv.org/display/PROJ/VNF+Event+Stream .. |image0| image:: Data_Model_For_Event_Records.png |