diff options
Diffstat (limited to 'docs/release/release-notes')
4 files changed, 42 insertions, 19 deletions
diff --git a/docs/release/release-notes/lab-description/index.rst b/docs/release/release-notes/lab-description/index.rst index 23b675ae..aed596e2 100644 --- a/docs/release/release-notes/lab-description/index.rst +++ b/docs/release/release-notes/lab-description/index.rst @@ -13,7 +13,14 @@ network topologies. Compute, network and storage specifications with network top required to help developers use lab resources efficiently while minimizing support needs. This also greatly assists with troubleshoting. It is the responsibility of the lab owner to keep individual lab documents updated and determine appropriate level of detail that is exposed publicly through -the Wiki or maintained in a secure Pharos repo with controlled access. +the Wiki or maintained in a secure Pharos repo +`securedlab <https://gerrit.opnfv.org/gerrit/#/admin/projects/securedlab>`_ with controlled access. +To avoid deplicated content, it is suggested to directly include the rst docs in the wiki. + +Before Danube release, securedlab is only opened for Infra WG committers and installer projects's +contributors. Since Euphrates release, it is opened for all the contributors of Pharos project, if +you are the owner of a community lab, please ask helpdesk to become a Pharos contributor in order +to submit your PDF to the securedlab repo. The goal of the Pharos Project is automation of resource provisioning. This requires machine readable inventory and network configuration files that follow common format. @@ -24,4 +31,4 @@ readable inventory and network configuration files that follow common format. ./lab_description.rst ./pod_description.rst - ./inventory.rst + ./pdf.rst diff --git a/docs/release/release-notes/lab-description/pdf.rst b/docs/release/release-notes/lab-description/pdf.rst new file mode 100644 index 00000000..4f53edb3 --- /dev/null +++ b/docs/release/release-notes/lab-description/pdf.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. + +******************** +Pod Description File +******************** + +The PDF(Pod Descrition File) provides template for POD's hardware information for all the +installers in yaml. The target is to use the same PDF file to deploy a POD by any installer with +any scenario it supports. It is the base of the dynamic CI , LaaS(Lab as a Service) and +SDF(Scenario Description File). + +Currently Jinja template is used to transfer the PDF to the specific installer's +template. PDF, Jinja template and the transfering tools are all stored in :ref:`securedlab`. +You can find the latest PDF template in +https://gerrit.opnfv.org/gerrit/#/c/38283/8/labs/lf/pod4.yaml. + diff --git a/docs/release/release-notes/specification/hardwarespec.rst b/docs/release/release-notes/specification/hardwarespec.rst index 8086aa91..1eb883e7 100644 --- a/docs/release/release-notes/specification/hardwarespec.rst +++ b/docs/release/release-notes/specification/hardwarespec.rst @@ -8,15 +8,16 @@ 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) +- One CentOS/Ubuntu jump server on which the virtualized Openstack/OPNFV installer runs. For an ARM + POD, the jump server should also be an ARM server +- 3 controller nodes +- 2 compute 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/octopus/brahmaputra/docs/octopus_docs/opnfv-jenkins-slave-connection.html#jenkins-slaves -http://artifacts.opnfv.org/brahmaputra.1.0/docs/opnfv-jenkins-slave-connection.brahmaputra.1.0.html +In the Euphrates release you may select a variety of deployment toolchains to deploy from the +jump server. **Servers** @@ -38,7 +39,7 @@ 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 second HDD is configured for CEPH OSD * 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) diff --git a/docs/release/release-notes/specification/objectives.rst b/docs/release/release-notes/specification/objectives.rst index 0a0ad6aa..dac50bfb 100644 --- a/docs/release/release-notes/specification/objectives.rst +++ b/docs/release/release-notes/specification/objectives.rst @@ -7,23 +7,20 @@ 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. +OPNFV platform release. 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 +- Supports the full Euphrates deployment lifecycle (this requires a **bare-metal** environment) +- Supports functional and performance testing of the Euphrates 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 +Deploying Euphrates 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 Euphrates release of OPNFV. The high level architecture is outlined in the following diagram: -.. image:: ../images/pharos-archi1.jpg +.. image:: ../../images/pharos-archi1.jpg |