docs: Fix long lines

OPNFVDOCS scripts set max line length to 240 chars. This patch
shortens long lines to avoid rst validation warnings during Auto
docs generation.

Change-Id: I124e3ea3aa04bc7fc8c2f5cf25ce9c75fdcef330
Signed-off-by: Martin Klozik <martin.klozik@tieto.com>

5 files changed, 91 insertions, 28 deletions

diff --git a/docs/release/configguide/Auto-featureconfig.rst b/docs/release/configguide/Auto-featureconfig.rst
index af16a9b..fe51be3 100644
--- a/docs/release/configguide/Auto-featureconfig.rst
+++ b/docs/release/configguide/Auto-featureconfig.rst
@@ -55,14 +55,19 @@ server with the OpenStack instance.
 .. image:: auto-installTarget-initial.jpg
 
 
-The OpenStack instance running VNFs may need to be configured as per ONAP expectations, for example creating instances of ONAP projects/tenants, users, security groups, networks (private, public), connected to the Internet by a Router, and making sure expected VM images and flavors are present. A script (using OpenStack SDK, or OpenStack CLI, or even OpenStack Heat templates) would populate the OpenStack instance, as illustrated below:
+The OpenStack instance running VNFs may need to be configured as per ONAP expectations, for example creating
+instances of ONAP projects/tenants, users, security groups, networks (private, public), connected to the
+Internet by a Router, and making sure expected VM images and flavors are present. A script (using OpenStack
+SDK, or OpenStack CLI, or even OpenStack Heat templates) would populate the OpenStack instance, as illustrated below:
 
 .. image:: auto-OS-config4ONAP.png
 
 
 
 Jenkins (or more precisely JJB: Jenkins Job Builder) will be used for Continuous Integration in OPNFV releases, to ensure that the latest master
-branch of Auto is always working. The first 3 tasks in the pipeline would be: install OpenStack instance via OPNFV installer (Fuel/MCP for example), configure the OpenStack instance for ONAP, install ONAP (using the OpenStack instance network IDs in the ONAP YAMP file).
+branch of Auto is always working. The first 3 tasks in the pipeline would be: install OpenStack instance via OPNFV
+installer (Fuel/MCP for example), configure the OpenStack instance for ONAP, install ONAP (using the OpenStack
+instance network IDs in the ONAP YAMP file).
 
 Moreover, Auto will offer an API, which can be imported as a module, and can be accessed for example
 by a web application. The following diagram shows the planned structure for the Auto Git repository,
diff --git a/docs/release/release-notes/Auto-release-notes.rst b/docs/release/release-notes/Auto-release-notes.rst
index 5318d09..2c2b6d0 100644
--- a/docs/release/release-notes/Auto-release-notes.rst
+++ b/docs/release/release-notes/Auto-release-notes.rst
@@ -23,15 +23,22 @@ OPNFV is a SDNFV system integration project for open-source components, which so
 
 In particular, OPNFV has yet to integrate higher-level automation features for VNFs and end-to-end Services.
 
-Auto ("ONAP-Automated OPNFV") will focus on ONAP component integration and verification with OPNFV reference platforms/scenarios, through primarily a post-install process in order to avoid impact to OPNFV installer projects. As much as possible, this will use a generic installation/integration process (not specific to any OPNFV installer's technology).
+Auto ("ONAP-Automated OPNFV") will focus on ONAP component integration and verification with OPNFV reference
+platforms/scenarios, through primarily a post-install process in order to avoid impact to OPNFV installer projects.
+As much as possible, this will use a generic installation/integration process (not specific to any OPNFV installer's
+technology).
 
 * `ONAP <https://www.onap.org/>`_ (a Linux Foundation Project) is an open source software platform that delivers robust capabilities for the design, creation, orchestration, monitoring, and life cycle management of Software-Defined Networks (SDNs).
 
 While all of ONAP is in scope, as it proceeds, the project will focus on specific aspects of this integration and verification in each release. Some example topics and work items include:
 
 * How ONAP meets VNFM standards, and interacts with VNFs from different vendors
-* How ONAP SDN-C uses OPNFV existing features, e.g. NetReady, in a two-layer controller architecture in which the upper layer (global controller) is replaceable, and the lower layer can use different vendor’s local controller to interact with SDN-C
-* What data collection interface VNF and controllers provide to ONAP DCAE, and (through DCAE), to closed-loop control functions such as Policy Tests which verify interoperability of ONAP automation/lifecycle features with specific NFVI and VIM features, as prioritized by the project with technical community and EUAG input. Examples include:
+* How ONAP SDN-C uses OPNFV existing features, e.g. NetReady, in a two-layer controller architecture in which the upper
+  layer (global controller) is replaceable, and the lower layer can use different vendor’s local controller to interact
+  with SDN-C
+* What data collection interface VNF and controllers provide to ONAP DCAE, and (through DCAE), to closed-loop control
+  functions such as Policy Tests which verify interoperability of ONAP automation/lifecycle features with specific NFVI
+  and VIM features, as prioritized by the project with technical community and EUAG input. Examples include:
 
   * Abstraction of networking tech/features e.g. through NetReady/Gluon
   * Blueprint-based VNF deployment (HOT, TOSCA, YANG)
@@ -52,7 +59,11 @@ Testability:
 * Tests will be developed for use cases within the project scope.
 * In future releases, tests will be added to Functest runs for supporting scenarios.
 
-Auto’s goals include the standup and tests for integrated ONAP-Cloud platforms (“Cloud” here being OPNFV “scenarios” or other cloud environments). Thus, the artifacts would be tools to deploy ONAP (leveraging OOM whenever possible (starting with Beijing release of ONAP), and a preference for the containerized version of ONAP), to integrate it with clouds, to onboard and deploy test VNFs, to configure policies and closed-loop controls, and to run use-case defined tests against that integrated environment. OPNFV scenarios would be a possible component in the above.
+Auto’s goals include the standup and tests for integrated ONAP-Cloud platforms (“Cloud” here being OPNFV “scenarios”
+or other cloud environments). Thus, the artifacts would be tools to deploy ONAP (leveraging OOM whenever possible
+(starting with Beijing release of ONAP), and a preference for the containerized version of ONAP), to integrate it with
+clouds, to onboard and deploy test VNFs, to configure policies and closed-loop controls, and to run use-case defined
+tests against that integrated environment. OPNFV scenarios would be a possible component in the above.
 
 Auto currently defines three use cases: Edge Cloud (UC1), Resiliency Improvements (UC2), and Enterprise vCPE (UC3). These use cases aim to show:
 
@@ -62,13 +73,24 @@ Auto currently defines three use cases: Edge Cloud (UC1), Resiliency Improvement
 
 The use cases define test cases, which initially will be independent, but which might eventually be integrated to `FuncTest <https://wiki.opnfv.org/display/functest/Opnfv+Functional+Testing>`_.
 
-Additional use cases can be added in the future, such as vIMS (example: project Clearwater) or residential vHGW (virtual Home Gateways). The interest for vHGW is to reduce overall power consumption: even in idle mode, physical HGWs in residential premises consume a lot of energy. Virtualizing that service to the Service Provider edge data center would allow to minimize that consumption.
+Additional use cases can be added in the future, such as vIMS (example: project Clearwater) or residential vHGW (virtual
+Home Gateways). The interest for vHGW is to reduce overall power consumption: even in idle mode, physical HGWs in
+residential premises consume a lot of energy. Virtualizing that service to the Service Provider edge data center would
+allow to minimize that consumption.
 
-Target architectures for all Auto use cases and test cases include x86 and Arm. Power consumption analysis will be performed, leveraging Functest tools.
+Target architectures for all Auto use cases and test cases include x86 and Arm. Power consumption analysis will be
+performed, leveraging Functest tools.
 
-An ONAP instance (without DCAE) has been installed over Kubernetes on bare metal on an x86 pod of 6 servers at UNH IOL. A transition is in progress, to leverage OPNFV LaaS (Lab-as-a-Service) pods (`Pharos <https://labs.opnfv.org/>`_). These pods can be booked for 3 weeks only (with an extension for a maximum of 2 weeks), so are not a permanent resource. A repeatable automated installation procedure is being developed. An installation of ONAP on Kubernetes in a public OpenStack cloud on an Arm server has been done, and demonstrated during OpenStack Summit in Vancouver on May 21st 2018 (see link in references below).
+An ONAP instance (without DCAE) has been installed over Kubernetes on bare metal on an x86 pod of 6 servers at UNH IOL.
+A transition is in progress, to leverage OPNFV LaaS (Lab-as-a-Service) pods (`Pharos <https://labs.opnfv.org/>`_).
+These pods can be booked for 3 weeks only (with an extension for a maximum of 2 weeks), so are not a permanent resource.
+A repeatable automated installation procedure is being developed. An installation of ONAP on Kubernetes in a public
+OpenStack cloud on an Arm server has been done, and demonstrated during OpenStack Summit in Vancouver on May 21st 2018
+(see link in references below).
 
-ONAP-based onboarding and deployment of VNFs is in progress (ONAP pre-loading of VNFs must still done outside of ONAP: for VM-based VNFs, need to prepare OpenStack stacks (using Heat templates), then make an instance snapshot which serves as the binary image of the VNF).
+ONAP-based onboarding and deployment of VNFs is in progress (ONAP pre-loading of VNFs must still done outside of ONAP:
+for VM-based VNFs, need to prepare OpenStack stacks (using Heat templates), then make an instance snapshot which serves
+as the binary image of the VNF).
 
 An initial version of a script to prepare an OpenStack instance for ONAP (creation of a public and a private network, with a router) has been developed.
 
diff --git a/docs/release/userguide/UC01-feature.userguide.rst b/docs/release/userguide/UC01-feature.userguide.rst
index ea02bad..5b5edb8 100644
--- a/docs/release/userguide/UC01-feature.userguide.rst
+++ b/docs/release/userguide/UC01-feature.userguide.rst
@@ -17,9 +17,12 @@ Description
 
 This use case aims at showcasing the benefits of using ONAP for autonomous Edge Cloud management.
 
-A high level of automation of VNF lifecycle event handling after launch is enabled by ONAP policies and closed-loop controls, which take care of most lifecycle events (start, stop, scale up/down/in/out, recovery/migration for HA) as well as their monitoring and SLA management.
+A high level of automation of VNF lifecycle event handling after launch is enabled by ONAP policies and closed-loop
+controls, which take care of most lifecycle events (start, stop, scale up/down/in/out, recovery/migration for HA) as
+well as their monitoring and SLA management.
 
-Multiple types of VNFs, for different execution environments, are first approved in the catalog thanks to the onboarding process, and then can be deployed and handled by multiple controllers in a systematic way.
+Multiple types of VNFs, for different execution environments, are first approved in the catalog thanks to the onboarding
+process, and then can be deployed and handled by multiple controllers in a systematic way.
 
 This results in management efficiency (lower control/automation overhead) and high degree of autonomy.
 
diff --git a/docs/release/userguide/UC02-feature.userguide.rst b/docs/release/userguide/UC02-feature.userguide.rst
index 3ed5781..9746914 100644
--- a/docs/release/userguide/UC02-feature.userguide.rst
+++ b/docs/release/userguide/UC02-feature.userguide.rst
@@ -15,15 +15,21 @@ specifically for Use Case 2: Resiliency Improvements Through ONAP.
 Description
 ===========
 
-This use case illustrates VNF failure recovery time reduction with ONAP, thanks to its automated monitoring and management. It:
+This use case illustrates VNF failure recovery time reduction with ONAP, thanks to its automated monitoring
+and management. It:
 
 * simulates an underlying problem (failure, stress, or any adverse condition in the network that can impact VNFs)
 * tracks a VNF
 * measures the amount of time it takes for ONAP to restore the VNF functionality.
 
-The benefit for NFV edge service providers is to assess what degree of added VIM+NFVI platform resilience for VNFs is obtained by leveraging ONAP closed-loop control, vs. VIM+NFVI self-managed resilience (which may not be aware of the VNF or the corresponding end-to-end Service, but only of underlying resources such as VMs and servers).
+The benefit for NFV edge service providers is to assess what degree of added VIM+NFVI platform resilience for VNFs
+is obtained by leveraging ONAP closed-loop control, vs. VIM+NFVI self-managed resilience (which may not be aware
+of the VNF or the corresponding end-to-end Service, but only of underlying resources such as VMs and servers).
 
-Also, a problem, or challenge, may not necessarily be a failure (which could also be recovered by other layers): it could be an issue leading to suboptimal performance, without failure. A VNF management layer as provided by ONAP may detect such non-failure problems, and provide a recovery solution which no other layer could provide in a given deployment.
+Also, a problem, or challenge, may not necessarily be a failure (which could also be recovered by other layers):
+it could be an issue leading to suboptimal performance, without failure. A VNF management layer as provided by
+ONAP may detect such non-failure problems, and provide a recovery solution which no other layer could provide
+in a given deployment.
 
 
 Preconditions:
@@ -33,9 +39,13 @@ Preconditions:
 #. ONAP has been deployed onto a cloud and is interfaced (i.e. provisioned for API access) to the Edge cloud
 #. Components of ONAP have been deployed on the Edge cloud as necessary for specific test objectives
 
-In future releases, Auto Use cases will also include the deployment of ONAP (if not already installed), the deployment of test VNFs (pre-existing VNFs in pre-existing ONAP can be used in the test as well), the configuration of ONAP for monitoring these VNFs (policies, CLAMP, DCAE), in addition to the test scripts which simulate a problem and measures recovery time.
+In future releases, Auto Use cases will also include the deployment of ONAP (if not already installed),
+the deployment of test VNFs (pre-existing VNFs in pre-existing ONAP can be used in the test as well),
+the configuration of ONAP for monitoring these VNFs (policies, CLAMP, DCAE), in addition to the test
+scripts which simulate a problem and measures recovery time.
 
-Different types of problems can be simulated, hence the identification of multiple test cases corresponding to this use case, as illustrated in this diagram:
+Different types of problems can be simulated, hence the identification of multiple test cases corresponding
+to this use case, as illustrated in this diagram:
 
 .. image:: auto-UC02-testcases.jpg
 
@@ -68,7 +78,9 @@ Test execution high-level description
 
 The following two MSCs (Message Sequence Charts) show the actors and high-level interactions.
 
-The first MSC shows the preparation activities (assuming the hardware, network, cloud, and ONAP have already been installed): onboarding and deployment of VNFs (via ONAP portal and modules in sequence: SDC, VID, SO), and ONAP configuration (policy framework, closed-loops in CLAMP, activation of DCAE).
+The first MSC shows the preparation activities (assuming the hardware, network, cloud, and ONAP have already
+been installed): onboarding and deployment of VNFs (via ONAP portal and modules in sequence: SDC, VID, SO),
+and ONAP configuration (policy framework, closed-loops in CLAMP, activation of DCAE).
 
 .. image:: auto-UC02-preparation.jpg
 
@@ -94,7 +106,9 @@ The high-level design of classes identifies several entities, described as follo
 * ``Test Definition`` : gathers all the information necessary to run a certain test case
 * ``Metric Definition`` : describes a certain metric that may be measured for a Test Case, in addition to Recovery Time
 * ``Challenge Definition`` : describe the challenge (problem, failure, stress, ...) simulated by the test case
-* ``Recipient`` : entity that can receive commands and send responses, and that is queried by the Test Definition or Challenge Definition (a recipient would be typically a management service, with interfaces (CLI or API) for clients to query)
+* ``Recipient`` : entity that can receive commands and send responses, and that is queried by the Test Definition
+  or Challenge Definition (a recipient would be typically a management service, with interfaces (CLI or API) for
+  clients to query)
 * ``Resources`` : with 3 types (VNF, cloud virtual resource such as a VM, physical resource such as a server)
 
 
@@ -119,7 +133,9 @@ This next diagram shows the Python classes and attributes, as implemented by thi
 
 Test definition data is stored in serialization files (Python pickles), while test execution data is stored in CSV files, for easier post-analysis.
 
-The module design is straightforward: functions and classes for managing data, for interfacing with recipients, for executing tests, and for interacting with the test user (choosing a Test Definition, showing the details of a Test Definition, starting the execution).
+The module design is straightforward: functions and classes for managing data, for interfacing with recipients,
+for executing tests, and for interacting with the test user (choosing a Test Definition, showing the details of
+a Test Definition, starting the execution).
 
 .. image:: auto-UC02-module1.jpg
 
@@ -134,18 +150,27 @@ In future releases of Auto, testing environments such as Robot, FuncTest and Yar
 Also, anonymized test results could be collected from users willing to share them, and aggregates could be
 maintained as benchmarks.
 
-As further illustration, the next figure shows cardinalities of class instances: one Test Definition per Test Case, multiple Test Executions per Test Definition, zero or one Recovery Time Metric Value per Test Execution (zero if the test failed for any reason, including if ONAP failed to recover the challenge), etc.
+As further illustration, the next figure shows cardinalities of class instances: one Test Definition per Test Case,
+multiple Test Executions per Test Definition, zero or one Recovery Time Metric Value per Test Execution (zero if
+the test failed for any reason, including if ONAP failed to recover the challenge), etc.
 
 .. image:: auto-UC02-cardinalities.png
 
 
-In this particular implementation, both Test Definition and Challenge Definition classes have a generic execution method (e.g., ``run_test_code()`` for Test Definition) which can invoke a particular script, by way of an ID (which can be configured, and serves as a script selector for each Test Definition instance). The overall test execution logic between classes is show in the next figure.
+In this particular implementation, both Test Definition and Challenge Definition classes have a generic execution method
+(e.g., ``run_test_code()`` for Test Definition) which can invoke a particular script, by way of an ID (which can be
+configured, and serves as a script selector for each Test Definition instance). The overall test execution logic
+between classes is show in the next figure.
 
 .. image:: auto-UC02-logic.png
 
-The execution of a test case starts with invoking the generic method from Test Definition, which then creates Execution instances, invokes Challenge Definition methods, performs the Recovery time calculation, performs script-specific actions, and writes results to the CSV files.
+The execution of a test case starts with invoking the generic method from Test Definition, which then creates Execution
+instances, invokes Challenge Definition methods, performs the Recovery time calculation, performs script-specific
+actions, and writes results to the CSV files.
 
-Finally, the following diagram show a mapping between these class instances and the initial test case design. It corresponds to the test case which simulates a VM failure, and shows how the OpenStack SDK API is invoked (with a connection object) by the Challenge Definition methods, to suspend and resume a VM.
+Finally, the following diagram show a mapping between these class instances and the initial test case design. It
+corresponds to the test case which simulates a VM failure, and shows how the OpenStack SDK API is invoked (with
+a connection object) by the Challenge Definition methods, to suspend and resume a VM.
 
 .. image:: auto-UC02-TC-mapping.png
 
diff --git a/docs/release/userguide/UC03-feature.userguide.rst b/docs/release/userguide/UC03-feature.userguide.rst
index cf96981..2c0d9e7 100644
--- a/docs/release/userguide/UC03-feature.userguide.rst
+++ b/docs/release/userguide/UC03-feature.userguide.rst
@@ -18,9 +18,14 @@ Description
 This Use Case shows how ONAP can help ensure that virtual CPEs (including vFW: virtual firewalls) in Edge Cloud are enterprise-grade.
 Other vCPE examples: vAAA, vDHCP, vDNS, vGW, vBNG, vRouter, ...
 
-ONAP operations include a verification process for VNF onboarding (i.e., inclusion in the ONAP catalog), with multiple Roles (Designer, Tester, Governor, Operator), responsible for approving proposed VNFs (as VSPs (Vendor Software Products), and eventually as end-to-end Services).
+ONAP operations include a verification process for VNF onboarding (i.e., inclusion in the ONAP catalog), with multiple
+Roles (Designer, Tester, Governor, Operator), responsible for approving proposed VNFs (as VSPs (Vendor Software Products),
+and eventually as end-to-end Services).
 
-This process guarantees a minimum level of quality of onboarded VNFs. If all deployed vCPEs are only chosen from such an approved ONAP catalog, the resulting deployed end-to-end vCPE services will meet enterprise-grade requirements. ONAP provides a NBI (currently HTTP-based) in addition to a standard GUI portal, thus enabling a programmatic deployment of VNFs, still conforming to ONAP processes.
+This process guarantees a minimum level of quality of onboarded VNFs. If all deployed vCPEs are only chosen from such an
+approved ONAP catalog, the resulting deployed end-to-end vCPE services will meet enterprise-grade requirements. ONAP
+provides a NBI (currently HTTP-based) in addition to a standard GUI portal, thus enabling a programmatic deployment of
+VNFs, still conforming to ONAP processes.
 
 Moreover, ONAP also comprises real-time monitoring (by the DCAE component), which can perform the following functions:
 
@@ -32,9 +37,12 @@ DCAE executes directives coming from policies described in the Policy Framework,
 
 ONAP can perform the provisioning side of a BSS Order Management application handling vCPE orders.
 
-Additional processing can be added to ONAP (internally as configured policies and closed-loop controls, or externally as separate systems): Path Computation Element and Load Balancing, and even telemetry-based Network Artificial Intelligence.
+Additional processing can be added to ONAP (internally as configured policies and closed-loop controls, or externally as
+separate systems): Path Computation Element and Load Balancing, and even telemetry-based Network Artificial Intelligence.
 
-Finally, this automated approach also reduces costs, since repetitive actions are designed once and executed multiple times, as vCPEs are instantiated and decommissioned (frequent events, given the variability of business activity, and a Small Business market similar to the Residential market: many contract updates resulting in many vCPE changes).
+Finally, this automated approach also reduces costs, since repetitive actions are designed once and executed multiple times,
+as vCPEs are instantiated and decommissioned (frequent events, given the variability of business activity, and a Small
+Business market similar to the Residential market: many contract updates resulting in many vCPE changes).
 
 NFV edge service providers need to provide site2site, site2dc (Data Center) and site2internet services to tenants both efficiently and safely, by deploying such qualified enterprise-grade vCPE.