From 988cf64e3a7601396e40b08a1aae07a524bf8c74 Mon Sep 17 00:00:00 2001 From: 10013968 Date: Mon, 18 Jul 2016 23:51:00 +0800 Subject: 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 --- docs/specification/hardwarespec.rst | 6 ++++-- docs/specification/networkconfig.rst | 12 ++++++++---- docs/specification/objectives.rst | 19 +++++++++++-------- docs/specification/remoteaccess.rst | 28 ++++++++++++++++++---------- 4 files changed, 41 insertions(+), 24 deletions(-) (limited to 'docs/specification') 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 `_ 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 + `_ 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 `_ + * Intel lights-out + `RMM `_ * HP lights-out `ILO `_ * CISCO lights-out `UCS `_ Linux Foundation Lab is a UCS-M hardware environment with controlled access *as needed* - * `Access rules and procedure `_ are maintained on the Wiki - * `A list of people `_ with access is maintained on the Wiki - * Send access requests to infra-steering@lists.opnfv.org with the following information ... + * `Access rules and procedure `_ are + maintained on the Wiki + * `A list of people `_ 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 + -- cgit 1.2.3-korg