Fix minot doc8 warnings in vnfsdk doc

JIRA: VNFSDK-127

Change-Id: I5cdc5958b72478cec8940578a88f367b95916f48
Signed-off-by: Morgan Richomme <morgan.richomme@orange.com>

1 files changed, 21 insertions, 22 deletions

diff --git a/docs/files/VNF SDK - Guide for Bundling VNFs.rst b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
index 5a4dc81..2cb1556 100644
--- a/docs/files/VNF SDK - Guide for Bundling VNFs.rst
+++ b/docs/files/VNF SDK - Guide for Bundling VNFs.rst
@@ -29,34 +29,34 @@ The "dependency" requirement should have a relationship of type
 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.
+   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.
+   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".
+   "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.
+   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.
+   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.
@@ -74,4 +74,3 @@ 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.
-