Reformat the rst documents

Main changes:
Set the textwidth to 100, exceptions: tables and http links may be
longer than the limits
Cut off the table width as shorten as possible

JIRA: PHAROS-227

Change-Id: I07861e675d76ab5063f388d3be7d0b51c8bad38b
Signed-off-by: 10013968 <zhang.jun3g@zte.com.cn>

4 files changed, 41 insertions, 24 deletions

diff --git a/docs/specification/hardwarespec.rst b/docs/specification/hardwarespec.rst
index a66e68f3..28165ebf 100644
--- a/docs/specification/hardwarespec.rst
+++ b/docs/specification/hardwarespec.rst
@@ -9,8 +9,10 @@ Hardware
 A pharos compliant OPNFV test-bed provides:
 
 - One CentOS 7 jump server on which the virtualized Openstack/OPNFV installer runs
-- In the Brahmaputra release you may select a variety of deployment toolchains to deploy from the jump server.
-- 5 compute / controller nodes (`BGS <https://wiki.opnfv.org/get_started/get_started_work_environment>`_ requires 5 nodes)
+- In the Brahmaputra release you may select a variety of deployment toolchains to deploy from the
+  jump server.
+- 5 compute / controller nodes (`BGS
+  <https://wiki.opnfv.org/get_started/get_started_work_environment>`_ requires 5 nodes)
 - A configured network topology allowing for LOM, Admin, Public, Private, and Storage Networks
 - Remote access as defined by the Jenkins slave configuration guide
 
diff --git a/docs/specification/networkconfig.rst b/docs/specification/networkconfig.rst
index 94477fc7..fa95faa5 100644
--- a/docs/specification/networkconfig.rst
+++ b/docs/specification/networkconfig.rst
@@ -9,9 +9,12 @@ Networking
 **Network Hardware**
 
   * 24 or 48 Port TOR Switch
-  * NICs - Combination of 1GE and 10GE based on network topology options (per server can be on-board or use PCI-e)
-  * Connectivity for each data/control network is through a separate NIC. This simplifies Switch Management however requires more NICs on the server and also more switch ports
-  * BMC (Baseboard Management Controller) for lights-out mangement network using IPMI (Intelligent Platform Management Interface)
+  * NICs - Combination of 1GE and 10GE based on network topology options (per server can be on-board
+    or use PCI-e)
+  * Connectivity for each data/control network is through a separate NIC. This
+    simplifies Switch Management however requires more NICs on the server and also more switch ports
+  * BMC (Baseboard Management Controller) for lights-out mangement network using IPMI (Intelligent
+    Platform Management Interface)
 
 **Network Options**
 
@@ -31,7 +34,8 @@ Networking
   * Option III: 2x1G Control, 2x10G Data, 2x10G Storage, 24 Port Switch
 
     * Data NIC used for VNF traffic
-    * Storage NIC used for control plane and Storage segmented through VLANs (separate host traffic from VNF)
+    * Storage NIC used for control plane and Storage segmented through VLANs (separate host traffic
+      from VNF)
     * 1 x 1G for lights-out mangement
     * 1 x 1G for Admin/PXE boot
     * 2 x 10G for control-plane connectivity/storage
diff --git a/docs/specification/objectives.rst b/docs/specification/objectives.rst
index f6cfabed..0a0ad6aa 100644
--- a/docs/specification/objectives.rst
+++ b/docs/specification/objectives.rst
@@ -6,20 +6,23 @@
 Pharos Compliance
 -----------------
 
-The **Pharos Specification** defines a hardware environment for deployment and testing of the **Brahmaputra**
-platform release. The **Pharos Project** is also responsible for defining lab capabilities, developing
-management/usage policies and process;  and a support plan for reliable access to project and release resources.
-Community labs are provided as a service by companies and are not controlled by Pharos however our objective is
-to provide easy visibility of all lab capabilities and their usage at all-times.
+The **Pharos Specification** defines a hardware environment for deployment and testing of the
+**Brahmaputra** platform release. The **Pharos Project** is also responsible for defining lab
+capabilities, developing management/usage policies and process;  and a support plan for reliable
+access to project and release resources.  Community labs are provided as a service by companies and
+are not controlled by Pharos however our objective is to provide easy visibility of all lab
+capabilities and their usage at all-times.
 
 Pharos lab infrastructure has the following objectives:
 - Provides secure, scalable, standard and HA environments for feature development
 - Supports the full Brahmaputra deployment lifecycle (this requires a **bare-metal** environment)
 - Supports functional and performance testing of the Brahmaputra release
-- Provides mechanisms and procedures for secure remote access to Pharos compliant environments for OPNFV community
+- Provides mechanisms and procedures for secure remote access to Pharos compliant environments for
+  OPNFV community
 
-Deploying Brahmaputra in a Virtualized environment is possible and will be useful, however it does not provide a fully
-featured deployment and realistic test environment for the Brahmaputra release of OPNFV.
+Deploying Brahmaputra in a Virtualized environment is possible and will be useful, however it does
+not provide a fully featured deployment and realistic test environment for the Brahmaputra release
+of OPNFV.
 
 The high level architecture is outlined in the following diagram:
 
diff --git a/docs/specification/remoteaccess.rst b/docs/specification/remoteaccess.rst
index 185eaa89..4b8160ba 100644
--- a/docs/specification/remoteaccess.rst
+++ b/docs/specification/remoteaccess.rst
@@ -9,11 +9,12 @@ Remote Management
 Remote access is required for …
 
   * Developers to access deploy/test environments (credentials to be issued per POD / user)
-  * Connection of each environment to Jenkins master hosted by Linux Foundation for automated deployment and test
+  * Connection of each environment to Jenkins master hosted by Linux Foundation for automated
+    deployment and test
 
-OpenVPN is generally used for remote however community hosted labs may vary due to company security rules. For POD
-access rules / restrictions refer to individual lab documentation as each company may have different access rules
-and acceptable usage policies.
+OpenVPN is generally used for remote however community hosted labs may vary due to company security
+rules. For POD access rules / restrictions refer to individual lab documentation as each company may
+have different access rules and acceptable usage policies.
 
 Basic requirements:
 
@@ -31,15 +32,19 @@ Lights-out management network requirements:
   * Access to server is through a lights-out-management tool and/or a serial console
   * Refer to applicable light-out mangement information from server manufacturer, such as ...
 
-    * Intel lights-out `RMM <http://www.intel.com/content/www/us/en/server-management/intel-remote-management-module.html>`_
+    * Intel lights-out
+      `RMM <http://www.intel.com/content/www/us/en/server-management/intel-remote-management-module.html>`_
     * HP lights-out `ILO <http://www8.hp.com/us/en/products/servers/ilo/index.html>`_
     * CISCO lights-out `UCS <https://developer.cisco.com/site/ucs-dev-center/index.gsp>`_
 
 Linux Foundation Lab is a UCS-M hardware environment with controlled access *as needed*
 
-    * `Access rules and procedure <https://wiki.opnfv.org/display/pharos/Lflab+Hosting>`_ are maintained on the Wiki
-    * `A list of people <https://wiki.opnfv.org/display/pharos/Lf+Support>`_ with access is maintained on the Wiki
-    * Send access requests to infra-steering@lists.opnfv.org with the following information ...
+    * `Access rules and procedure <https://wiki.opnfv.org/display/pharos/Lflab+Hosting>`_ are
+      maintained on the Wiki
+    * `A list of people <https://wiki.opnfv.org/display/pharos/Lf+Support>`_ with access is
+      maintained on the Wiki
+    * Send access requests to infra-steering@lists.opnfv.org with the
+      following information ...
 
       * Name:
       * Company:
@@ -50,6 +55,9 @@ Linux Foundation Lab is a UCS-M hardware environment with controlled access *as
       * What specific POD/machines will be accessed:
       * What support is needed from LF admins and LF community support team:
 
-    * Once access is approved please follow instructions for setting up VPN access
+    * Once access is approved please follow instructions for setting up VPN access ...
+      https://wiki.opnfv.org/get_started/lflab_hosting
     * The people who require VPN access must have a valid PGP key bearing a valid signature from LF
-    * When issuing OpenVPN credentials, LF will be sending TLS certificates and 2-factor authentication tokens, encrypted to each recipient's PGP key
+    * When issuing OpenVPN credentials, LF will be sending TLS certificates and 2-factor
+      authentication tokens, encrypted to each recipient's PGP key
+