[docs] Refresh for Gambia release

- s/Fuel@OPNFV/OPNFV Fuel/g;
- added README files for ci/scenarios/patches directories;
- refresh & simplify cluster overview diagrams;
- unify labels across docs;
- fix TOC numbering;
- remove local labs PDF/IDF files, as they are merely duplicates of
  Pharos files included as a git submodule;

JIRA: FUEL-397

Change-Id: I87f61938eeb67f13fd9205d5226a30f02e55d267
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>

2 files changed, 78 insertions, 82 deletions

diff --git a/ci/README.rst b/ci/README.rst
index dc860c003..c25c58f11 100644
--- a/ci/README.rst
+++ b/ci/README.rst
@@ -4,99 +4,100 @@
 
 Abstract
 ========
-The fuel/ci directory holds all Fuel@OPNFV programatic abstractions for
-the OPNFV community release and continous integration pipeline.
-There is now only one Fuel@OPNFV autonomous script for this, complying to the
+
+The ``ci`` directory holds all OPNFV Fuel programatic abstractions for
+the OPNFV community release and continuous integration pipeline.
+There are now two OPNFV Fuel autonomous scripts for this, complying to the
 OPNFV CI pipeline guideline:
- - deploy.sh
 
-USAGE
+- ``build.sh``
+- ``deploy.sh``
+
+Usage
 =====
-For usage information of the CI/CD scripts, please run:
 
-    .. code-block:: bash
+For usage information of the CI/CD deploy script, please run:
 
-        $ ./deploy.sh -h
+.. code-block:: console
 
-Details on the CI/CD deployment framework
+    jenkins@jumpserver:~/fuel/ci$ ./deploy.sh -h
+
+Details on the CI/CD Deployment Framework
 =========================================
 
-Overview and purpose
+Overview and Purpose
 --------------------
-The CI/CD deployment script relies on a configuration structure, providing base
-installer configuration (part of fuel repo: mcp/config), per POD specific
-configuration (part of a separate classified POD configuration repo: securedlab
-and deployment scenario configuration (part of fuel repo: mcp/config/scenario).
 
-- The base installer configuration resembles the least common denominator of all
+The CI/CD deployment script relies on a configuration structure, providing:
+
+- per POD specific configuration (defaults to using Pharos OPNFV project
+  ``PDF``/``IDF`` files for all OPNFV CI PODs).
+  Pharos OPNFV git repository is included as a git submodule at
+  ``mcp/scripts/pharos``.
+  Optionally, a custom configuration structure can be used via the ``-b``
+  deploy argument.
+  The POD specific parameters follow the ``PDF``/``IDF`` formats defined by
+  the Pharos OPNFV project.
+- deployment scenario configuration, part of fuel repo: ``mcp/config/scenario``.
+  Provides a high level, POD/HW environment independent scenario configuration
+  for a specific deployment. It defines what features shall be deployed - as
+  well as needed overrides of the base installer, POD/HW environment
+  configurations. Objects allowed to override are governed by the OPNFV Fuel
+  project.
+- base installer configuration, part of fuel repo: ``mcp/config/states``,
+  ``mcp/reclass``.
+  The base installer configuration resembles the least common denominator of all
   HW/POD environment and deployment scenarios. These configurations are
-  normally carried by the the installer projects in this case (Fuel@OPNFV).
-- Per POD specific configuration specifies POD unique parameters, the POD
-  parameter possible to alter is governed by the Fuel@OPNFV project.
-- Deployment scenario configuration - provides a high level, POD/HW environment
-  independent scenario configuration for a specifiv deployment. It defines what
-  features shall be deployed - as well needed overrides of the base
-  installer, POD/HW environment configurations. Objects allowed to override
-  are governed by the Fuel@OPNFV project.
-
-Executing a deployment
+  normally carried by the the installer projects in this case (OPNFV Fuel).
+
+Executing a Deployment
 ----------------------
-deploy.sh must be executed locally at the target lab/pod/jumpserver
+
+``deploy.sh`` must be executed locally on the target lab/pod/jumpserver.
 A configuration structure must be provided - see the section below.
 It is straight forward to execute a deployment task - as an example:
 
-    .. code-block:: bash
+.. code-block:: console
+
+    jenkins@jumpserver:~/fuel/ci$ ./deploy.sh -b file:///home/jenkins/config \
+                                              -l lf \
+                                              -p pod2 \
+                                              -s os-nosdn-nofeature-ha
 
-        $ sudo deploy.sh -b file:///home/jenkins/config
-                         -l lf -p pod2 -s os-nosdn-nofeature-ha
+``-b`` argument should be expressed in URI style (eg: ``file://...`` or
+``http://...``). The resources can thus be local or remote.
 
--b and -i arguments should be expressed in URI style (eg: file://...
-or http://...). The resources can thus be local or remote.
+If ``-b`` is not used, the Pharos OPNFV project git submodule local path URI
+is used for the default configuration structure.
 
-Configuration repository structure
+Configuration Repository Structure
 ----------------------------------
+
 The CI deployment engine relies on a configuration directory/file structure
-pointed to by the -b option described above.
-Normally this points to the secure classified OPNFV securedlab repo to which
-only jenkins and andmins have access to, but you may point to any local or
-remote strcture fullfilling the diectory/file structure below.
-The reason that this configuration structure needs to be secure/hidden
-is that there are security sensitive information in the various configuration
-files.
-
-FIXME: Below information is out of date and should be refreshed after PDF
-support is fully implemented.
-
-A local stripped version of this configuration structure with virtual
-deployment configurations also exist under build/config/.
+pointed to by the ``-b`` option described above.
+Normally this points to the ``mcp/scripts/pharos`` git repo submodule, but you
+may point to any local or remote strcture fullfilling the diectory/file
+structure below.
+This configuration structure supports optional encryption of certain security
+sensitive data, mechanism described in the Pharos documentation.
+
 Following configuration directory and file structure should adheare to:
 
-    .. code-block:: bash
-
-        TOP
-        !
-        +---- labs
-               !
-               +---- lab-name-1
-               !        !
-               !        +---- pod-name-1
-               !        !        !
-               !        !        +---- fuel
-               !        !               !
-               !        !               +---- config
-               !        !                       !
-               !        !                       +---- dea-pod-override.yaml
-               !        !                       !
-               !        !                       +---- dha.yaml
-               !        !
-               !        +---- pod-name-2
-               !                 !
-               !
-               +---- lab-name-2
-               !        !
-
-
-Creating a deployment scenario
-------------------------------
-Please find `mcp/config/README.rst` for instructions on how to create a new
-deployment scenario.
+.. code-block:: console
+
+    TOP
+    !
+    +---- labs
+           !
+           +---- lab-name-1
+           !        !
+           !        +---- pod1.yaml
+           !        !
+           !        +---- idf-pod1.yaml
+           !        !
+           !        +---- pod2.yaml
+           !        !
+           !        +---- idf-pod2.yaml
+           !
+           +---- lab-name-2
+           !        !
diff --git a/ci/deploy.sh b/ci/deploy.sh
index a899970fe..a61946e6c 100755
--- a/ci/deploy.sh
+++ b/ci/deploy.sh
@@ -32,7 +32,7 @@ usage ()
 {
 cat << EOF
 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-$(notify "$(basename "$0"): Deploy the Fuel@OPNFV MCP stack" 3)
+$(notify "$(basename "$0"): Deploy the OPNFV Fuel MCP stack" 3)
 
 $(notify "USAGE:" 2)
   $(basename "$0") -l lab-name -p pod-name -s deploy-scenario \\
@@ -59,9 +59,9 @@ $(notify "OPTIONS:" 2)
   -N  Experimental: Do not virtualize control plane (novcp)
 
 $(notify_i "Description:" 2)
-Deploys the Fuel@OPNFV stack on the indicated lab resource.
+Deploys the OPNFV Fuel stack on the indicated lab resource.
 
-This script provides the Fuel@OPNFV deployment abstraction.
+This script provides the OPNFV Fuel deployment abstraction.
 It depends on the OPNFV official configuration directory/file structure
 and provides a fairly simple mechanism to execute a deployment.
 
@@ -74,8 +74,6 @@ $(notify_i "Input parameters to the build script are:" 2)
    <base-uri>/labs/<lab-name>/idf-<pod-name>.yaml
    The default is using the git submodule tracking 'OPNFV Pharos' in
    <./mcp/scripts/pharos>.
-   An example config is provided inside current repo in
-   <./mcp/config>, automatically linked as <./mcp/scripts/pharos/labs/local>.
 -d Dry-run - Produce deploy config files, but do not execute deploy
 -D Debug logging - Enable extra logging in sh deploy scripts (set -x)
 -e Do not launch environment deployment
@@ -92,10 +90,7 @@ $(notify_i "Input parameters to the build script are:" 2)
 -h Print this message and exit
 -L Deployment log path and name, eg. -L /home/jenkins/job.log.tar.gz
 -l Lab name as defined in the configuration directory, e.g. lf
-   For the sample configuration in <./mcp/config>, lab name is 'local'.
 -p POD name as defined in the configuration directory, e.g. pod2
-   For the sample configuration in <./mcp/config>, POD name is 'virtual1'
-   for virtual deployments or 'pod1' for baremetal (based on lf-pod2).
 -m Use single socket compute nodes. Instead of using default NUMA-enabled
    topology for virtual compute nodes created via libvirt, configure a
    single guest CPU socket.