Corrections to pass doc8

Change-Id: I753838f44e3c82563b6f272a9a38264398b644cf
Issue-ID: DOC-94
Signed-off-by: Eric Debeau <eric.debeau@orange.com>

1 files changed, 77 insertions, 78 deletions

diff --git a/docs/files/VNF SDK - Guide for Bundling VNFs.rst b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
index b5a3499..5a4dc81 100644
--- a/docs/files/VNF SDK - Guide for Bundling VNFs.rst
+++ b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
@@ -1,78 +1,77 @@
-VNF SDK - Guide for Bundling VNFs    

-=================================

-

-

-Step 1: Requirements

---------------------

-

-1. Virtual machine images for each of your VDUs (likely in qcow2 format).

-2. Scripts for installing and configuring each VDU per the standard TOSCA lifecycle workflows.

-3. Optional: scripts for retrieving indicators from each VDU.

-4. VNF SDK pkgtools

-

-Step 2: Start with the provided VNF blueprint as a template

------------------------------------------------------------

-

-The VNF SDK comes with a "pingpong.yaml" template.

-

-Copy the file and rename it as is appropriate for your VNF.

-

-Step 3: Edit the VNF blueprint

-------------------------------

-

-You will need a node template for each VDU, which in turn has a "dependency" 

-requirement on a host (a Compute node template).

-

-The "dependency" requirement should have a relationship of type 

-"vnfsdk.DependsOn".

-

-There are two optional properties you can assign to this relationship:

-

-1. "indicators" is a map of indicators. The keys are arbitrary, for you to name, 

-  and depend on the specific capabilities of your VNF. These provide the link 

-  between TOSCA and your indicator retrieval scripts.

-2. "compute_dependencies" is a map of features you require the infrastructure to 

-  provide for the compute node hosting your VDU. The keys are arbitrary, however 

-  we will maintain a master list of names supported by various orchestrators 

-  (TBD). Note that new names will likely be supported in the future as 

-  technological innovation progresses, while deprecated ones will be ignored by 

-  orchestrators. Likewise, names unsupported by a particular orchestrator will 

-  be ignored.

-

-Notes:

-

-1. For "compute_dependencies", you have the option of specifying a single special key, "profile", that refers to a bundle of compute dependencies specified in 

-  "compute-profiles.yaml". Optionally, you can override any of the dependencies 

-  in the bundle by specifying them explicitly under "compute_dependencies".

-  

-2. By default, compute dependencies are considered to be absolute requirements 

-  for your VNF to function. However, if your VNF can also function without them, 

-  you can set "optional: true". This way the orchestrator will try to satisfy 

-  the optional requirements, but will not report an error if it cannot.

-3. You may optionally consider allowing operators to override your dependencies. 

-  This is useful for allowing the VNF to run on various compute infrastructures 

-  other than the defaults you specify, as long as they are indeed supported by 

-  your VNF. In TOSCA, this is easily handled by declaring "inputs" for your 

-  blueprint, with "default" values, and then using the "get_input" intrinsic 

-  function to apply the provided value to any specific "compute_dependencies". 

-  The "pingpong.yaml" has an example of such usage. The same technique can be 

-  used to allow the operator to override your indicator scripts, and there is an 

-  example of that as well.

-

-Otherwise, this is a standard TOSCA blueprint using the Simple Profile for NFV, 

-and you may extend the blueprint as is required.

-

-Step 4: Bundle the VNF

-----------------------

-

-Arrange all your files (the TOSCA template, your scripts, and your virtual 

-machine images) in the correct directory structure. File references provided in 

-the blueprint must match the directory structure. If a script is referenced 

-using a path with sub-directory "example" the initial directory must contain a 

-directory called "example" with that script file inside. The directory structure 

-will be kept inside the CSAR archive.

-

-Run the bundling tool that is included in the VNF SDK.

-

-The result will be a ".csar" file that can now be deployed by operators.

-

+VNF SDK - Guide for Bundling VNFs
+=================================
+
+
+Step 1: Requirements
+--------------------
+
+1. Virtual machine images for each of your VDUs (likely in qcow2 format).
+2. Scripts for installing and configuring each VDU per the standard TOSCA lifecycle workflows.
+3. Optional: scripts for retrieving indicators from each VDU.
+4. VNF SDK pkgtools
+
+Step 2: Start with the provided VNF blueprint as a template
+-----------------------------------------------------------
+
+The VNF SDK comes with a "pingpong.yaml" template.
+
+Copy the file and rename it as is appropriate for your VNF.
+
+Step 3: Edit the VNF blueprint
+------------------------------
+
+You will need a node template for each VDU, which in turn has a "dependency"
+requirement on a host (a Compute node template).
+
+The "dependency" requirement should have a relationship of type
+"vnfsdk.DependsOn".
+
+There are two optional properties you can assign to this relationship:
+
+1. "indicators" is a map of indicators. The keys are arbitrary, for you to name,
+  and depend on the specific capabilities of your VNF. These provide the link
+  between TOSCA and your indicator retrieval scripts.
+2. "compute_dependencies" is a map of features you require the infrastructure to
+  provide for the compute node hosting your VDU. The keys are arbitrary, however
+  we will maintain a master list of names supported by various orchestrators
+  (TBD). Note that new names will likely be supported in the future as
+  technological innovation progresses, while deprecated ones will be ignored by
+  orchestrators. Likewise, names unsupported by a particular orchestrator will
+  be ignored.
+
+Notes:
+
+1. For "compute_dependencies", you have the option of specifying a single special key, "profile", that refers to a bundle of compute dependencies specified in
+  "compute-profiles.yaml". Optionally, you can override any of the dependencies
+  in the bundle by specifying them explicitly under "compute_dependencies".
+2. By default, compute dependencies are considered to be absolute requirements
+  for your VNF to function. However, if your VNF can also function without them,
+  you can set "optional: true". This way the orchestrator will try to satisfy
+  the optional requirements, but will not report an error if it cannot.
+3. You may optionally consider allowing operators to override your dependencies.
+  This is useful for allowing the VNF to run on various compute infrastructures
+  other than the defaults you specify, as long as they are indeed supported by
+  your VNF. In TOSCA, this is easily handled by declaring "inputs" for your
+  blueprint, with "default" values, and then using the "get_input" intrinsic
+  function to apply the provided value to any specific "compute_dependencies".
+  The "pingpong.yaml" has an example of such usage. The same technique can be
+  used to allow the operator to override your indicator scripts, and there is an
+  example of that as well.
+
+Otherwise, this is a standard TOSCA blueprint using the Simple Profile for NFV,
+and you may extend the blueprint as is required.
+
+Step 4: Bundle the VNF
+----------------------
+
+Arrange all your files (the TOSCA template, your scripts, and your virtual
+machine images) in the correct directory structure. File references provided in
+the blueprint must match the directory structure. If a script is referenced
+using a path with sub-directory "example" the initial directory must contain a
+directory called "example" with that script file inside. The directory structure
+will be kept inside the CSAR archive.
+
+Run the bundling tool that is included in the VNF SDK.
+
+The result will be a ".csar" file that can now be deployed by operators.
+