[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>
(cherry picked from commit 170d2d1c195d001d6ca786364aaf3c10e714ae36)

1 files changed, 80 insertions, 78 deletions

diff --git a/mcp/patches/README.rst b/mcp/patches/README.rst
index 735b70341..28af0e8f7 100644
--- a/mcp/patches/README.rst
+++ b/mcp/patches/README.rst
@@ -1,30 +1,30 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. SPDX-License-Identifier: CC-BY-4.0
-.. (c) 2017 Mirantis Inc., Enea AB and others.
+.. (c) 2018 Mirantis Inc., Enea AB and others.
 
 ==========================================
-Fuel@OPNFV submodule fetching and patching
+OPNFV Fuel Submodule Fetching and Patching
 ==========================================
 
 This directory holds submodule fetching/patching scripts, intended for
-working with upstream Fuel/MCP components (e.g.: reclass-system-salt-model) in
-developing/applying OPNFV patches (backports, custom fixes etc.).
+working with upstream Fuel/MCP components (e.g.: ``reclass-system-salt-model``)
+in developing/applying OPNFV patches (backports, custom fixes etc.).
 
 The scripts should be friendly to the following 2 use-cases:
 
-  - development work: easily cloning, binding repos to specific commits,
-    remote tracking, patch development etc.;
-  - to provide parent build scripts an easy method of tracking upstream
-    references and applying OPNFV patches on top;
+- development work: easily cloning, binding repos to specific commits,
+  remote tracking, patch development etc.;
+- to provide parent build scripts an easy method of tracking upstream
+  references and applying OPNFV patches on top;
 
 Also, we need to support at least the following modes of operations:
 
-  - submodule bind - each submodule patches will be based on the commit ID
-    saved in the .gitmodules config file;
-  - remote tracking - each submodule will sync with the upstream remote
-    and patches will be applied on top of <sub_remote>/<sub_branch>/HEAD;
+- submodule bind - each submodule patches will be based on the commit ID
+  saved in the ``.gitmodules`` config file;
+- remote tracking - each submodule will sync with the upstream remote
+  and patches will be applied on top of ``<sub_remote>/<sub_branch>/HEAD``;
 
-Workflow (development)
+Workflow (Development)
 ======================
 
 The standard development workflow should look as follows:
@@ -32,114 +32,116 @@ The standard development workflow should look as follows:
 Decide whether remote tracking should be active or not
 ------------------------------------------------------
 
-NOTE: Setting the following var to any non-empty str enables remote track.
+.. NOTE::
 
-NOTE: Leaving unset will enable remote track for anything but stable branch.
+    Setting the following var to any non-empty str enables remote track.
 
-    .. code-block:: bash
+.. code-block:: console
 
-        $ export FUEL_TRACK_REMOTES=""
+    developer@machine:~/fuel$ export FUEL_TRACK_REMOTES=""
 
 Initialize git submodules
 -------------------------
 
-All Fuel sub-projects are registered as submodules.
+All Fuel direct dependency projects are registered as submodules.
 If remote tracking is active, upstream remote is queried and latest remote
-branch HEAD is fetched. Otherwise, checkout commit IDs from .gitmodules.
+branch ``HEAD`` is fetched. Otherwise, checkout commit IDs from ``.gitmodules``.
 
-    .. code-block:: bash
+.. code-block:: console
 
-        $ make sub
+    developer@machine:~/fuel$ make -C mcp/patches sub
 
-Apply patches from `patches/<sub-project>/*` to respective submodules
----------------------------------------------------------------------
+Apply patches from ``patches/<sub-project>/*`` to respective submodules
+-----------------------------------------------------------------------
 
 This will result in creation of:
 
-- a tag called `${FUEL_MAIN_TAG}-opnfv-root` at the same commit as Fuel@OPNFV
-  upstream reference (bound to git submodule OR tracking remote HEAD);
-- a new branch `opnfv-fuel` which will hold all the OPNFV patches,
-  each patch is applied on this new branch with `git-am`;
-- a tag called `${FUEL_MAIN_TAG}-opnfv` at `opnfv-fuel/HEAD`;
+- a tag called ``${F_OPNFV_TAG}-root`` at the same commit as OPNFV Fuel
+  upstream reference (bound to git submodule OR tracking remote ``HEAD``);
+- a new branch ``nightly`` which will hold all the OPNFV patches,
+  each patch is applied on this new branch with ``git-am``;
+- a tag called ``${F_OPNFV_TAG}`` at ``nightly/HEAD``;
+- for each (sub)directory of ``patches/<sub-project>``, another pair of tags
+  ``${F_OPNFV_TAG}-<sub-directory>-fuel/patch-root`` and
+  ``${F_OPNFV_TAG}-<sub-directory>-fuel/patch`` are also created;
 
-    .. code-block:: bash
+.. code-block:: console
 
-        $ make patches-import
+    developer@machine:~/fuel$ make -C mcp/patches patches-import
 
 Modify sub-projects for whatever you need
 -----------------------------------------
 
-Commit your changes when you want them taken into account in the build.
+To add/change OPNFV-specific patches for a sub-project:
 
-Re-create patches
+- commit your changes inside the git submodule(s);
+- move the git tag to the new reference so ``make patches-export`` will
+  pick up the new commit later;
+
+.. code-block:: console
+
+    developer@machine:~/fuel$ cd ./path/to/submodule
+    developer@machine:~/fuel/path/to/submodule$ # ...
+    developer@machine:~/fuel/path/to/submodule$ git commit
+    developer@machine:~/fuel/path/to/submodule$ git tag -f ${F_OPNFV_TAG}-fuel/patch
+
+Re-create Patches
 -----------------
 
-Each commit on `opnfv-fuel` branch of each subproject will be
-exported to `patches/subproject/` via `git format-patch`.
+Each commit on ``nightly`` branch of each subproject will be
+exported to ``patches/subproject/`` via ``git format-patch``.
+
+.. NOTE::
+
+    Only commit submodule file changes when you need to bump upstream refs.
 
-NOTE: Only commit (-f) submodules when you need to bump upstream ref.
+.. WARNING::
 
-NOTE: DO NOT commit patched submodules!
+    DO NOT commit patched submodules!
 
-    .. code-block:: bash
+.. code-block:: console
 
-        $ make patches-export
+    developer@machine:~/fuel$ make -C mcp/patches patches-export patches-copyright
 
-Clean workbench branches and tags
+Clean Workbench Branches and Tags
 ---------------------------------
 
-    .. code-block:: bash
+.. code-block:: console
 
-        $ make clean
+    developer@machine:~/fuel$ make -C mcp/patches clean
 
-De-initialize submodules and force a clean clone
+De-initialize Submodules and Force a Clean Clone
 ------------------------------------------------
 
-    .. code-block:: bash
+.. code-block:: console
 
-        $ make deepclean
+    developer@machine:~/fuel$ make -C mcp/patches deepclean
 
-Sub-project maintenance
+Sub-project Maintenance
 =======================
 
-Adding a new submodule
+Adding a New Submodule
 ----------------------
 
-If you need to add another subproject, you can do it with `git submodule`.
-Make sure that you specify branch (with `-b`), short name (with `--name`):
-
-    .. code-block:: bash
-
-        $ git submodule -b master add --name reclass-system-salt-model
-          https://github.com/Mirantis/reclass-system-salt-model
-          relative/path/to/submodule
-
-Working with remote tracking for upgrading Fuel components
-----------------------------------------------------------
-
-Enable remote tracking as described above, which at `make sub` will update
-ALL submodules (e.g. reclass-system-salt-model) to remote branch (set in
-.gitmodules) HEAD.
+If you need to add another subproject, you can do it with ``git submodule``.
+Make sure that you specify branch (with ``-b``), short name (with ``--name``):
 
-* If upstream has NOT already tagged a new version, we can still work on
-  our patches, make sure they apply etc., then check for new upstream
-  changes (and that our patches still apply on top of them) by:
+.. code-block:: console
 
-* If upstream has already tagged a new version we want to pick up, checkout
-  the new tag in each submodule:
+    developer@machine:~/fuel$ git submodule -b master add --name reclass-system-salt-model \
+                              https://github.com/Mirantis/reclass-system-salt-model \
+                              mcp/reclass/classes/system
 
-* Once satisfied with the patch and submodule changes, commit them:
+Working with Remote Tracking
+----------------------------
 
-  - enforce FUEL_TRACK_REMOTES to "yes" if you want to constatly use the
-    latest remote branch HEAD (as soon as upstream pushes a change on that
-    branch, our next build will automatically include it - risk of our
-    patches colliding with new upstream changes);
-  - stage patch changes if any;
-  - if submodule tags have been updated (relevant when remote tracking is
-    disabled, i.e. we have a stable upstream baseline), add submodules;
+Enable remote tracking as described above, which at ``make sub`` will update
+ALL submodules (e.g. ``reclass-system-salt-model``) to remote branch (set in
+``.gitmodules``) ``HEAD``.
 
-        .. code-block:: bash
+.. WARNING::
 
-            $ make deepclean patches-import
-            $ git submodule foreach 'git checkout <newtag>'
-            $ make deepclean sub && git add -f relative/path/to/submodule
+    Enforce ``FUEL_TRACK_REMOTES`` to ``yes`` only if you want to constatly
+    use the latest remote branch ``HEAD`` (as soon as upstream pushes a change
+    on that branch, our next build will automatically include it - risk of our
+    patches colliding with new upstream changes) - for **ALL** submodules.