From 920646aba6ee52f5cf494e1f2c279230b664ece0 Mon Sep 17 00:00:00 2001 From: ChristopherPrice Date: Sun, 10 Jan 2016 15:27:07 +0100 Subject: [PATCH] Created a pharos specification docment according to the new toolchain. Created docs/specification and the index.rst fil in the new format for the new toolchain sequence. Will create a specification/index.html link on artifacts and associate pdf document. Made small editorials to the origincal content, but it needs work. Left the original pharos-spec file as it being worked on still. Should be removed once the spcification docs are in equivalent shape. Change-Id: I6edb121766e7e1fdf1f38c70be95347b81b71dcc Signed-off-by: ChristopherPrice --- docs/configguide/configguide.rst | 5 ++ docs/specification/hardwarespec.rst | 44 +++++++++++++++++ docs/specification/index.rst | 19 ++++++++ docs/specification/jumpserverinstall.rst | 83 ++++++++++++++++++++++++++++++++ docs/specification/networkconfig.rst | 74 ++++++++++++++++++++++++++++ docs/specification/objectives.rst | 20 ++++++++ docs/specification/remoteaccess.rst | 58 ++++++++++++++++++++++ 7 files changed, 303 insertions(+) create mode 100644 docs/configguide/configguide.rst create mode 100644 docs/specification/hardwarespec.rst create mode 100644 docs/specification/index.rst create mode 100644 docs/specification/jumpserverinstall.rst create mode 100644 docs/specification/networkconfig.rst create mode 100644 docs/specification/objectives.rst create mode 100644 docs/specification/remoteaccess.rst diff --git a/docs/configguide/configguide.rst b/docs/configguide/configguide.rst new file mode 100644 index 00000000..92d23b72 --- /dev/null +++ b/docs/configguide/configguide.rst @@ -0,0 +1,5 @@ +Pharos Lab Configuration requirements +===================================== + +Add an overview for the Pharos configuration guide here. This should be informative regarding the tasks +and expectations when configuring a lab to be pharos compliant and refer to the relevant pharos docs published from the project. diff --git a/docs/specification/hardwarespec.rst b/docs/specification/hardwarespec.rst new file mode 100644 index 00000000..a861b7dd --- /dev/null +++ b/docs/specification/hardwarespec.rst @@ -0,0 +1,44 @@ +Pharos compliant environment +---------------------------- + +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/arno.2015.1.0/docs/opnfv-jenkins-slave-connection.arno.2015.1.0.pdf + +Hardware requirements +--------------------- + +**Servers** + +CPU: + +* Intel Xeon E5-2600v2 Series +(Ivy Bridge and newer, or similar) + +Local Storage Configuration: + +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 may +produce a better result. + +* Disks: 2 x 1TB + 1 x 100GB SSD +* The first 1TB HDD should be used for OS & additional software/tool installation +* The second 1TB HDD configured for CEPH object storage +* Finally, the 100GB SSD should be used as the CEPH journal +* Performance testing requires a mix of compute nodes that have 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 + +* Single power supply acceptable (redundant power not required/nice to have) diff --git a/docs/specification/index.rst b/docs/specification/index.rst new file mode 100644 index 00000000..39764efe --- /dev/null +++ b/docs/specification/index.rst @@ -0,0 +1,19 @@ +Pharos Specification +==================== + +.. toctree:: + :maxdepth: 2 + + ./objectives.rst + ./hardwarespec.rst + ./networkconfig.rst + ./jumpserverinstall.rst + ./remoteaccess.rst + +:Authors: Trevor Cooper (Intel) +:Version: 1.0 + +Indices and tables +================== + +* :ref:`search` diff --git a/docs/specification/jumpserverinstall.rst b/docs/specification/jumpserverinstall.rst new file mode 100644 index 00000000..a82c3352 --- /dev/null +++ b/docs/specification/jumpserverinstall.rst @@ -0,0 +1,83 @@ +**Jump Server Configuration:** + +(Rough Placeholder, edit me) + +**Fuel** + +1. Obtain CentOS 7 Minimal ISO and install + + ``wget http://mirrors.kernel.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1503-01.iso`` + +2. Set parameters appropriate for your environment during installation + +3. Disable NetworkManager + + ``systemctl disable NetworkManager`` + +4. Configure your /etc/sysconfig/network-scripts/ifcfg-* files for your network + +5. Restart networking + + ``service network restart`` + +6. Edit /etc/resolv.conf and add a nameserver + + ``vi /etc/resolv.conf`` + +7. Install libvirt & kvm + + ``yum -y update`` + ``yum -y install kvm qemu-kvm libvirt`` + ``systemctl enable libvirtd`` + +8. Reboot: + + ``shutdown -r now`` + +9. If you wish to avoid annoying delay when use ssh to log in, disable DNS lookups: + + ``vi /etc/ssh/sshd_config`` + + Uncomment "UseDNS yes", change 'yes' to 'no'. + + Save + +10. Restart sshd + + ``systemctl restart sshd`` + +11. Install virt-install + + ``yum -y install virt-install`` + +12. Visit artifacts.opnfv.org and D/L the OPNFV Fuel ISO + +13. Create a bridge using the interface on the PXE network, for example: br0 + +14. Make a directory owned by qemu: + + ``mkdir /home/qemu; mkdir -p /home/qemu/VMs/fuel-6.0/disk`` + + ``chown -R qemu:qemu /home/qemu`` + +15. Copy the ISO to /home/qemu + + ``cd /home/qemu`` + + ``virt-install -n opnfv-2015-05-22_18-34-07-fuel -r 4096 --vcpus=4 + --cpuset=0-3 -c opnfv-2015-05-22_18-34-07.iso --os-type=linux + --os-variant=rhel6 --boot hd,cdrom --disk + path=/home/qemu/VMs/mirantis-fuel-6.0/disk/fuel-vhd0.qcow2,bus=virtio,size=50,format=qcow2 + -w bridge=br0,model=virtio --graphics vnc,listen=0.0.0.0`` + +16. Temporarily flush the firewall rules to make things easier: + + ``iptables -F`` + +17. Connect to the console of the installing VM with your favorite VNC client. + +18. Change the IP settings to match the pod, use an IP in the PXE/Admin network for the Fuel Master + +**Foreman** + +TBA diff --git a/docs/specification/networkconfig.rst b/docs/specification/networkconfig.rst new file mode 100644 index 00000000..510ea802 --- /dev/null +++ b/docs/specification/networkconfig.rst @@ -0,0 +1,74 @@ +Networking +---------- + +Test-bed network + +* 24 or 48 Port TOR Switch +* NICS - 1GE, 10GE - per server can be on-board or PCI-e +* Connectivity for each data/control network is through a separate NIC. + *This simplifies Switch Management howeverrequires more NICs on the server and also more switch ports +* Lights-out network can share with Admin/Management + +Network Interfaces + +* Option I: 4x1G Control, 2x40G Data, 48 Port Switch + + * 1 x 1G for ILMI (Lights out Management ) + * 1 x 1G for Admin/PXE boot + * 1 x 1G for control Plane connectivity + * 1 x 1G for storage + * 2 x 40G (or 10G) for data network (redundancy, NIC bonding, High bandwidth testing) + +* Option II: 1x1G Control, 2x 40G (or 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, 2x40G 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 IPMI + * 1 x 1G for Admin/PXE boot + * 2 x 10G for control plane connectivity/Storage + * 2 x 40G (or 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 + +ontroller node bridge topology overview + +.. image:: ../images/bridge1.png + +compute node bridge topology overview + +.. image:: ../images/bridge2.png + +Architecture +------------- + +** Network Diagram ** + +The Pharos architecture may be described as follow: +Figure 1: Standard Deployment Environment + +.. image:: ../images/opnfv-pharos-diagram-v01.jpg + +Figure 1: Standard Deployment Environment + +Sample Network Drawings +----------------------- + +Files for documenting lab network layout. +These were contributed as Visio VSDX format compressed as a ZIP +file. Here is a sample of what the visio looks like. + +Download the visio zip file here: +`opnfv-example-lab-diagram.vsdx.zip +`_ + +.. image:: ../images/opnfv-example-lab-diagram.png diff --git a/docs/specification/objectives.rst b/docs/specification/objectives.rst new file mode 100644 index 00000000..53423882 --- /dev/null +++ b/docs/specification/objectives.rst @@ -0,0 +1,20 @@ +Objectives / Scope +------------------- + +The Pharos specification defines the OPNFV hardware environment +upon which the OPNFV Brahmaputra platform release can be deployed +on and tested. This specification defines: + +- A secure, scalable, standard and HA environment +- 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 the test environment + +Deploying Brahmaputra in a Virtualized environment is possible +and will be useful, however it does not provide a fully +featured deployment and 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 new file mode 100644 index 00000000..e91d55e1 --- /dev/null +++ b/docs/specification/remoteaccess.rst @@ -0,0 +1,58 @@ +Remote management +------------------ + +**Remote access** + +- Remote access is required for … + + 1. Developers to access deploy/test environments (credentials to be issued per POD / user) + 2. 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 +- POD access rules / restrictions … + + - Refer to individual test-bed as each company may have different access rules and acceptable usage policies + +- Basic requirement is for SSH sessions to be established (initially on jump server) +- Majority of packages installed on a system (tools or applications) will be pulled from an external repo. + +Firewall rules should include + +- SSH sessions +- Jenkins sessions + +Lights-out Management: + +- Out-of-band management for power on/off/reset and bare-metal provisioning +- Access to server is through lights-out-management tool and/or a serial console +- 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 - VPN service for accessing Lights-Out +Management (LOM) infrastructure for the UCS-M hardware + +- People with admin access to LF infrastructure: + +1. amaged@cisco.com +2. cogibbs@cisco.com +3. daniel.smith@ericsson.com +4. dradez@redhat.com +5. fatih.degirmenci@ericsson.com +6. fbrockne@cisco.com +7. jonas.bjurel@ericsson.com +8. jose.lausuch@ericsson.com +9. joseph.gasparakis@intel.com +10. morgan.richomme@orange.com +11. pbandzi@cisco.com +12. phladky@cisco.com +13. stefan.k.berg@ericsson.com +14. szilard.cserey@ericsson.com +15. trozet@redhat.com + +- The people who require VPN access must have a valid +PGP key bearing a valid signature from one of these +three people. When issuing OpenVPN credentials, LF +will be sending TLS certificates and 2-factor +authentication tokens, encrypted to each recipient's PGP key. + -- 2.16.6