diff options
author | julien zhang <zhang.jun3g@zte.com.cn> | 2017-09-14 12:26:58 +0000 |
---|---|---|
committer | Gerrit Code Review <gerrit@opnfv.org> | 2017-09-14 12:26:58 +0000 |
commit | 51095fef7299f4fd05afbb542a0ce5fb0431ea2b (patch) | |
tree | a28c1570a1172874578aa1d76086d86f166a2c9a /docs/release/release-notes | |
parent | c795eab899e6a602d7d8009a4b5875019bd25a80 (diff) | |
parent | d8ed4f63a5af8f8836c8951623e6760ddb15710e (diff) |
Merge "Update contents in E release"
Diffstat (limited to 'docs/release/release-notes')
3 files changed, 22 insertions, 18 deletions
diff --git a/docs/release/release-notes/lab-description/index.rst b/docs/release/release-notes/lab-description/index.rst index 3782829f..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. diff --git a/docs/release/release-notes/specification/hardwarespec.rst b/docs/release/release-notes/specification/hardwarespec.rst index 8086aa91..f4d7530a 100644 --- a/docs/release/release-notes/specification/hardwarespec.rst +++ b/docs/release/release-notes/specification/hardwarespec.rst @@ -8,15 +8,15 @@ 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 +- 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 +38,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 |