restruct documents according to opnfvdocs

Use only development and release for we don't have test codes for now.

JIRA: PHAROS-311

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

5 files changed, 224 insertions, 0 deletions

diff --git a/docs/release/release-notes/specification/hardwarespec.rst b/docs/release/release-notes/specification/hardwarespec.rst
new file mode 100644
index 00000000..8086aa91
--- /dev/null
+++ b/docs/release/release-notes/specification/hardwarespec.rst
@@ -0,0 +1,52 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) 2016 OPNFV.
+
+
+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)
+- A configured network topology allowing for LOM, Admin, Public, Private, and Storage Networks
+- Remote access as defined by the Jenkins slave configuration guide
+
+http://artifacts.opnfv.org/brahmaputra.1.0/docs/opnfv-jenkins-slave-connection.brahmaputra.1.0.html
+
+**Servers**
+
+**CPU:**
+
+* Intel Xeon E5-2600v2 Series or newer
+* AArch64 (64bit ARM architecture) compatible (ARMv8 or newer)
+
+**Firmware:**
+
+* BIOS/EFI compatible for x86-family blades
+* EFI compatible for AArch64 blades
+
+**Local Storage:**
+
+Below describes the minimum for the Pharos spec, which is designed to provide enough capacity for
+a reasonably functional environment. Additional and/or faster disks are nice to have and mayproduce
+a better result.
+
+* Disks: 2 x 1TB HDD + 1 x 100GB SSD (or greater capacity)
+* The first HDD should be used for OS & additional software/tool installation
+* The second HDD is configured for CEPH object storage
+* The SSD should be used as the CEPH journal
+* Performance testing requires a mix of compute nodes with CEPH (Swift+Cinder) and without CEPH storage
+* Virtual ISO boot capabilities or a separate PXE boot server (DHCP/tftp or Cobbler)
+
+**Memory:**
+
+* 32G RAM Minimum
+
+**Power Supply**
+
+* Single power supply acceptable (redundant power not required/nice to have)
diff --git a/docs/release/release-notes/specification/index.rst b/docs/release/release-notes/specification/index.rst
new file mode 100644
index 00000000..c3eb45a7
--- /dev/null
+++ b/docs/release/release-notes/specification/index.rst
@@ -0,0 +1,18 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) 2016 OPNFV.
+
+.. Top level of Pharos specification documents.
+
+********************
+Pharos Specification
+********************
+
+The Pharos Specification provides information on Pharos hardware and network requirements
+
+.. toctree::
+
+   ./objectives.rst
+   ./hardwarespec.rst
+   ./networkconfig.rst
+   ./remoteaccess.rst
diff --git a/docs/release/release-notes/specification/networkconfig.rst b/docs/release/release-notes/specification/networkconfig.rst
new file mode 100644
index 00000000..fb9d5111
--- /dev/null
+++ b/docs/release/release-notes/specification/networkconfig.rst
@@ -0,0 +1,62 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) 2016 OPNFV.
+
+
+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)
+
+**Network Options**
+
+  * Option I: 4x1G Control, 2x10G Data, 48 Port Switch
+
+    * 1 x 1G for lights-out Management
+    * 1 x 1G for Admin/PXE boot
+    * 1 x 1G for control-plane connectivity
+    * 1 x 1G for storage
+    * 2 x 10G for data network (redundancy, NIC bonding, High bandwidth testing)
+
+  * Option II: 1x1G Control, 2x 10G Data, 24 Port Switch
+
+    * Connectivity to networks is through VLANs on the Control NIC
+    * Data NIC used for VNF traffic and storage traffic segmented through VLANs
+
+  * 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)
+    * 1 x 1G for lights-out mangement
+    * 1 x 1G for Admin/PXE boot
+    * 2 x 10G for control-plane connectivity/storage
+    * 2 x 10G for data network
+
+Documented configuration to include:
+
+ - Subnet, VLANs (may be constrained by existing lab setups or rules)
+ - IPs
+ - Types of NW - lights-out, public, private, admin, storage
+ - May be special NW requirements for performance related projects
+ - Default gateways
+
+**Sample Network Drawings**
+
+.. image:: ../../images/bridge2.png
+
+.. image:: ../../images/opnfv-pharos-diagram-v01.jpg
+
+.. image:: ../../images/opnfv-example-lab-diagram.png
+
+Download the visio zip file here:
+`opnfv-example-lab-diagram.vsdx.zip
+<https://wiki.opnfv.org/_media/opnfv-example-lab-diagram.vsdx.zip>`_
diff --git a/docs/release/release-notes/specification/objectives.rst b/docs/release/release-notes/specification/objectives.rst
new file mode 100644
index 00000000..0a0ad6aa
--- /dev/null
+++ b/docs/release/release-notes/specification/objectives.rst
@@ -0,0 +1,29 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) 2016 OPNFV.
+
+
+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.
+
+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
+
+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:
+
+.. image:: ../images/pharos-archi1.jpg
diff --git a/docs/release/release-notes/specification/remoteaccess.rst b/docs/release/release-notes/specification/remoteaccess.rst
new file mode 100644
index 00000000..4b8160ba
--- /dev/null
+++ b/docs/release/release-notes/specification/remoteaccess.rst
@@ -0,0 +1,63 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) 2016 OPNFV.
+
+
+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
+
+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:
+
+  * SSH sessions to be established (initially on the jump server)
+  * Packages to be installed on a system (tools or applications) by pullig from an external repo.
+
+Firewall rules accomodate:
+
+  * SSH sessions
+  * Jenkins sessions
+
+Lights-out management network requirements:
+
+  * Out-of-band management for power on/off/reset and bare-metal provisioning
+  * 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>`_
+    * 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 ...
+
+      * Name:
+      * Company:
+      * Approved Project:
+      * Project role:
+      * Why is access needed:
+      * How long is access needed (either a specified time period or define "done"):
+      * 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 ...
+      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
+