From 2e816cb9b91778d476dbd6e7f59040c50168df0a Mon Sep 17 00:00:00 2001 From: "Bozawglanian, Hagop (hb755d)" Date: Mon, 30 Jul 2018 16:07:02 +0000 Subject: VNFRQTS - Dynamic footnote generation Updating footnotes to be generated more dynamically. Change-Id: If0f18874009cc981e73db99ea95cbd9bc5fb6299 Issue-ID: VNFRQTS-279 Signed-off-by: Bozawglanian, Hagop (hb755d) --- docs/Chapter4/Design.rst | 4 ++-- docs/Chapter4/Devops.rst | 12 ++++++------ docs/Chapter7/Configuration-Management.rst | 16 ++++++++-------- docs/Chapter7/Monitoring-And-Management.rst | 4 ++-- docs/Chapter8/Chef-JSON-Key-Value-Description.rst | 4 ++-- 5 files changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/Chapter4/Design.rst b/docs/Chapter4/Design.rst index 70f5598..a4288d0 100644 --- a/docs/Chapter4/Design.rst +++ b/docs/Chapter4/Design.rst @@ -162,7 +162,7 @@ VNF Design Requirements :keyword: MUST The VNF **MUST** use the NCSP's supported library and compute - flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_ + flavor that supports DPDK to optimize network efficiency if using DPDK. [#4.1.1]_ .. req:: :id: R-18864 @@ -191,6 +191,6 @@ VNF Design Requirements The VNF **MUST NOT** require the use of a dynamic routing protocol unless necessary to meet functional requirements. -.. [1] +.. [#4.1.1] Refer to NCSP’s Network Cloud specification diff --git a/docs/Chapter4/Devops.rst b/docs/Chapter4/Devops.rst index aabd76f..589e382 100644 --- a/docs/Chapter4/Devops.rst +++ b/docs/Chapter4/Devops.rst @@ -46,14 +46,14 @@ DevOps Requirements :keyword: MUST The VNF **MUST** install the NCSP required software on Guest OS - images when not using the NCSP provided Guest OS images. [1]_ + images when not using the NCSP provided Guest OS images. [#4.5.1]_ .. req:: :id: R-09467 :target: VNF :keyword: MUST - The VNF **MUST** utilize only NCSP standard compute flavors. [1]_ + The VNF **MUST** utilize only NCSP standard compute flavors. [#4.5.1]_ .. req:: :id: R-02997 @@ -115,7 +115,7 @@ DevOps Requirements :target: VNF :keyword: MUST - The VNF **MUST** respond to a "move traffic" [2]_ command + The VNF **MUST** respond to a "move traffic" [#4.5.2]_ command against a specific VNFC, moving all existing session elsewhere with minimal disruption if a VNF provides a load balancing function across multiple instances of its VNFCs. @@ -128,7 +128,7 @@ DevOps Requirements :target: VNF :keyword: MUST - The VNF **MUST** respond to a "drain VNFC" [2]_ command against + The VNF **MUST** respond to a "drain VNFC" [#4.5.2]_ command against a specific VNFC, preventing new session from reaching the targeted VNFC, with no disruption to active sessions on the impacted VNFC, if a VNF provides a load balancing function across multiple instances of its VNFCs. @@ -145,10 +145,10 @@ DevOps Requirements testing and operations. -.. [1] +.. [#4.5.1] Refer to NCSP’s Network Cloud specification -.. [2] +.. [#4.5.2] Not currently supported in ONAP release 1 diff --git a/docs/Chapter7/Configuration-Management.rst b/docs/Chapter7/Configuration-Management.rst index 8adb330..c650f7a 100644 --- a/docs/Chapter7/Configuration-Management.rst +++ b/docs/Chapter7/Configuration-Management.rst @@ -752,7 +752,7 @@ NETCONF Server Requirements :keyword: MUST The xNF PACKAGE **MUST** validated YANG code using the open - source pyang [1]_ program using the following commands: + source pyang [#7.3.1]_ program using the following commands: .. code-block:: python @@ -1182,7 +1182,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 [2]_. As part of this process, it will + endpoint) by replicating it [#7.3.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 @@ -1245,7 +1245,7 @@ Ansible Client Requirements The xNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a xNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server - for invocation of playbooks against these end points [3]_. + for invocation of playbooks against these end points [#7.3.3]_. .. req:: :id: R-54373 @@ -1326,7 +1326,7 @@ complete the desired action. :keyword: MUST The xNF **MUST** support each ONAP (APPC) xNF action - by invocation of **one** playbook [4]_. The playbook will be responsible + by invocation of **one** playbook [#7.3.4]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request. @@ -1660,18 +1660,18 @@ Table 8. ONAP Controller APIs and NETCONF Commands | | | |results. | +-------------+--------------------+--------------------+--------------------+ -.. [1] +.. [#7.3.1] https://github.com/mbj4668/pyang -.. [2] +.. [#7.3.2] 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”. -.. [3] +.. [#7.3.3] Upstream elements must provide the appropriate FQDN in the request to ONAP for the desired action. -.. [4] +.. [#7.3.4] Multiple ONAP actions may map to one playbook. diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst index 38edab8..4ef2eae 100644 --- a/docs/Chapter7/Monitoring-And-Management.rst +++ b/docs/Chapter7/Monitoring-And-Management.rst @@ -372,7 +372,7 @@ JSON The xNF **MUST** encode and serialize content delivered to ONAP using JSON (RFC 7159) plain text format. High-volume data is to be encoded and serialized using `Avro `_, - where the Avro [1]_ data format are described using JSON. + where the Avro [#7.4.1]_ data format are described using JSON. Note: @@ -684,7 +684,7 @@ Security Information (SPI) or certain proprietary data, in addition to applying the regular procedures for securing access and delivery. -.. [1] +.. [#7.4.1] This option is not currently supported in ONAP and it is currently under consideration. diff --git a/docs/Chapter8/Chef-JSON-Key-Value-Description.rst b/docs/Chapter8/Chef-JSON-Key-Value-Description.rst index 7144159..8a51a85 100644 --- a/docs/Chapter8/Chef-JSON-Key-Value-Description.rst +++ b/docs/Chapter8/Chef-JSON-Key-Value-Description.rst @@ -127,7 +127,7 @@ a. The JSON file must be created for each action for each VNF. b. If a VNF action involves multiple endpoints (VMs) of a VNF, ONAP will replicate the “Node” JSON dictionary in the template and post it to each FQDN (i.e., endpoint) in the NodeList after setting the “name” - field in the Node object to be the respective FQDN [1]_. Hence, it + field in the Node object to be the respective FQDN [#8.1.1]_. Hence, it is required that all end points (VMs) of a VNF involved in a VNF action support the same set of Node Object attributes. @@ -173,6 +173,6 @@ Table A2. JSON Dictionary to Post in Callback | | to be returned to ONAP. | | be included. | +--------------+----------------------------+---------+-----------------------+ -.. [1] +.. [#8.1.1] The “name” field is a mandatory field in a valid Chef Node Object JSON dictionary. -- cgit 1.2.3-korg