From aa88673c38be12368dead5e8241fb915d790c431 Mon Sep 17 00:00:00 2001 From: Julien Date: Thu, 17 Aug 2017 21:32:10 +0800 Subject: 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 --- docs/specification/hardwarespec.rst | 52 ----------------------------- docs/specification/index.rst | 18 ----------- docs/specification/networkconfig.rst | 62 ----------------------------------- docs/specification/objectives.rst | 29 ----------------- docs/specification/remoteaccess.rst | 63 ------------------------------------ 5 files changed, 224 deletions(-) delete mode 100644 docs/specification/hardwarespec.rst delete mode 100644 docs/specification/index.rst delete mode 100644 docs/specification/networkconfig.rst delete mode 100644 docs/specification/objectives.rst delete mode 100644 docs/specification/remoteaccess.rst (limited to 'docs/specification') diff --git a/docs/specification/hardwarespec.rst b/docs/specification/hardwarespec.rst deleted file mode 100644 index 8086aa91..00000000 --- a/docs/specification/hardwarespec.rst +++ /dev/null @@ -1,52 +0,0 @@ -.. 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 - `_ 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/specification/index.rst b/docs/specification/index.rst deleted file mode 100644 index c3eb45a7..00000000 --- a/docs/specification/index.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. 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/specification/networkconfig.rst b/docs/specification/networkconfig.rst deleted file mode 100644 index fa95faa5..00000000 --- a/docs/specification/networkconfig.rst +++ /dev/null @@ -1,62 +0,0 @@ -.. 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 -`_ diff --git a/docs/specification/objectives.rst b/docs/specification/objectives.rst deleted file mode 100644 index 0a0ad6aa..00000000 --- a/docs/specification/objectives.rst +++ /dev/null @@ -1,29 +0,0 @@ -.. 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/specification/remoteaccess.rst b/docs/specification/remoteaccess.rst deleted file mode 100644 index 4b8160ba..00000000 --- a/docs/specification/remoteaccess.rst +++ /dev/null @@ -1,63 +0,0 @@ -.. 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 `_ - * 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 ... - - * 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 - -- cgit 1.2.3-korg