summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--README10
-rw-r--r--README.rst3
-rw-r--r--ci/README.rst (renamed from ci/README)70
-rw-r--r--mcp/config/scenario/README.rst (renamed from mcp/config/scenario/README.md)14
-rw-r--r--mcp/patches/README.md103
-rw-r--r--mcp/patches/README.rst145
-rw-r--r--prototypes/sfc_tacker/README54
-rw-r--r--prototypes/sfc_tacker/README.rst62
8 files changed, 253 insertions, 208 deletions
diff --git a/README b/README
deleted file mode 100644
index 4629763a3..000000000
--- a/README
+++ /dev/null
@@ -1,10 +0,0 @@
-##############################################################################
-# Copyright (c) 2015 Ericsson AB and others.
-# stefan.k.berg@ericsson.com
-# jonas.bjurel@ericsson.com
-# All rights reserved. This program and the accompanying materials
-# are made available under the terms of the Apache License, Version 2.0
-# which accompanies this distribution, and is available at
-# http://www.apache.org/licenses/LICENSE-2.0
-##############################################################################
-
diff --git a/README.rst b/README.rst
new file mode 100644
index 000000000..e1b9201aa
--- /dev/null
+++ b/README.rst
@@ -0,0 +1,3 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) 2017 Ericsson AB, Mirantis Inc., Enea AB and others.
diff --git a/ci/README b/ci/README.rst
index 898442559..dc860c003 100644
--- a/ci/README
+++ b/ci/README.rst
@@ -1,12 +1,6 @@
-##############################################################################
-# Copyright (c) 2017 Ericsson AB, Mirantis Inc., Enea Software AB and others.
-# stefan.k.berg@ericsson.com
-# jonas.bjurel@ericsson.com
-# All rights reserved. This program and the accompanying materials
-# are made available under the terms of the Apache License, Version 2.0
-# which accompanies this distribution, and is available at
-# http://www.apache.org/licenses/LICENSE-2.0
-##############################################################################
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) 2017 Ericsson AB, Mirantis Inc., Enea Software AB and others.
Abstract
========
@@ -19,7 +13,10 @@ OPNFV CI pipeline guideline:
USAGE
=====
For usage information of the CI/CD scripts, please run:
-./deploy.sh -h
+
+ .. code-block:: bash
+
+ $ ./deploy.sh -h
Details on the CI/CD deployment framework
=========================================
@@ -47,8 +44,11 @@ Executing a deployment
deploy.sh must be executed locally at 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:
-$ sudo deploy.sh -b file:///home/jenkins/config \
- -l lf -p pod2 -s os-nosdn-nofeature-ha
+
+ .. code-block:: bash
+
+ $ sudo deploy.sh -b file:///home/jenkins/config
+ -l lf -p pod2 -s os-nosdn-nofeature-ha
-b and -i arguments should be expressed in URI style (eg: file://...
or http://...). The resources can thus be local or remote.
@@ -71,30 +71,32 @@ A local stripped version of this configuration structure with virtual
deployment configurations also exist under build/config/.
Following configuration directory and file structure should adheare to:
-TOP
-!
-+---- labs
- !
- +---- lab-name-1
- ! !
- ! +---- pod-name-1
- ! ! !
- ! ! +---- fuel
- ! ! !
- ! ! +---- config
- ! ! !
- ! ! +---- dea-pod-override.yaml
- ! ! !
- ! ! +---- dha.yaml
- ! !
- ! +---- pod-name-2
- ! !
- !
- +---- lab-name-2
- ! !
+ .. 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 deploy/scenario/README for instructions on how to create a new
+Please find `mcp/config/README.rst` for instructions on how to create a new
deployment scenario.
diff --git a/mcp/config/scenario/README.md b/mcp/config/scenario/README.rst
index 6ecf05f32..389877ac4 100644
--- a/mcp/config/scenario/README.md
+++ b/mcp/config/scenario/README.rst
@@ -1,15 +1,15 @@
-##############################################################################
-# Copyright (c) 2017 Mirantis Inc., Enea AB and others.
-# All rights reserved. This program and the accompanying materials
-# are made available under the terms of the Apache License, Version 2.0
-# which accompanies this distribution, and is available at
-# http://www.apache.org/licenses/LICENSE-2.0
-##############################################################################
+.. 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.
+
+Fuel@OPNFV Scenario Configuration
+=================================
Abstract:
---------
This directory contains configuration files for different OPNFV deployment
feature scenarios used by Fuel@OPNFV, e.g.:
+
- High availability configuration;
- Type of SDN controller to be deployed;
- OPNFV collaboration project features to be deployed;
diff --git a/mcp/patches/README.md b/mcp/patches/README.md
deleted file mode 100644
index eab4d64e3..000000000
--- a/mcp/patches/README.md
+++ /dev/null
@@ -1,103 +0,0 @@
-Fuel@OPNFV 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.).
-
-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;
-
-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;
-
-Workflow (development)
-----------------------
-The standard development workflow should look as follows:
-
-1. Decide whether remote tracking should be active or not:
- NOTE: Setting the following var to any non-empty str enables remote track.
- NOTE: Leaving unset will enable remote track for anything but stable branch.
-
- $ export FUEL_TRACK_REMOTES=""
-
-2. All Fuel sub-projects are registered as submodules. To initialize them, call:
- If remote tracking is active, upstream remote is queried and latest remote
- branch HEAD is fetched. Otherwise, checkout commit IDs from .gitmodules.
-
- $ make sub
-
-3. Apply patches from `patches/<sub-project>/*` to respective submodules via:
-
- $ make patches-import
-
- 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`;
-
-4. Modify sub-projects for whatever you need.
- Commit your changes when you want them taken into account in the build.
-
-5. Re-create patches via:
-
- $ make patches-export
-
- Each commit on `opnfv-fuel` branch of each subproject will be
- exported to `patches/subproject/` via `git format-patch`.
-
- NOTE: Only commit (-f) submodules when you need to bump upstream ref.
- NOTE: DO NOT commit patched submodules!
-
-6. Clean workbench branches and tags with:
-
- $ make clean
-
-7. De-initialize submodules and force a clean clone with:
-
- $ make deepclean
-
-Sub-project maintenance
------------------------
-1. 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`):
-
- $ git submodule -b master add --name reclass-system-salt-model \
- https://github.com/Mirantis/reclass-system-salt-model \
- relative/path/to/submodule
-
-2. 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 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:
-
- $ make deepclean patches-import
-
- * If upstream has already tagged a new version we want to pick up, checkout
- the new tag in each submodule:
-
- $ git submodule foreach 'git checkout <newtag>'
-
- * Once satisfied with the patch and submodule changes, commit them:
- - 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:
-
- $ make deepclean sub && git add -f relative/path/to/submodule
diff --git a/mcp/patches/README.rst b/mcp/patches/README.rst
new file mode 100644
index 000000000..735b70341
--- /dev/null
+++ b/mcp/patches/README.rst
@@ -0,0 +1,145 @@
+.. 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.
+
+==========================================
+Fuel@OPNFV 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.).
+
+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;
+
+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;
+
+Workflow (development)
+======================
+
+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: Leaving unset will enable remote track for anything but stable branch.
+
+ .. code-block:: bash
+
+ $ export FUEL_TRACK_REMOTES=""
+
+Initialize git submodules
+-------------------------
+
+All Fuel sub-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.
+
+ .. code-block:: bash
+
+ $ make sub
+
+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`;
+
+ .. code-block:: bash
+
+ $ make patches-import
+
+Modify sub-projects for whatever you need
+-----------------------------------------
+
+Commit your changes when you want them taken into account in the build.
+
+Re-create patches
+-----------------
+
+Each commit on `opnfv-fuel` branch of each subproject will be
+exported to `patches/subproject/` via `git format-patch`.
+
+NOTE: Only commit (-f) submodules when you need to bump upstream ref.
+
+NOTE: DO NOT commit patched submodules!
+
+ .. code-block:: bash
+
+ $ make patches-export
+
+Clean workbench branches and tags
+---------------------------------
+
+ .. code-block:: bash
+
+ $ make clean
+
+De-initialize submodules and force a clean clone
+------------------------------------------------
+
+ .. code-block:: bash
+
+ $ make deepclean
+
+Sub-project maintenance
+=======================
+
+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 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:
+
+* If upstream has already tagged a new version we want to pick up, checkout
+ the new tag in each submodule:
+
+* Once satisfied with the patch and submodule changes, commit them:
+
+ - 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;
+
+ .. code-block:: bash
+
+ $ make deepclean patches-import
+ $ git submodule foreach 'git checkout <newtag>'
+ $ make deepclean sub && git add -f relative/path/to/submodule
diff --git a/prototypes/sfc_tacker/README b/prototypes/sfc_tacker/README
deleted file mode 100644
index 0208b7850..000000000
--- a/prototypes/sfc_tacker/README
+++ /dev/null
@@ -1,54 +0,0 @@
-# author: Ferenc Cserepkei <ferenc.cserepkei@ericsson.com>
-#
-# (c) 2016 Telefonaktiebolaget L. M. ERICSSON
-#
-# All rights reserved. This program and the accompanying materials
-# are made available under the terms of the Apache License, Version 2.0
-# which accompanies this distribution, and is available at
-# http://www.apache.org/licenses/LICENSE-2.0
-
-README SFC + Tacker
--------------------
-
- The Enclosed shell script builds, deploys, orchestrates Tacker,
-an Open NFV Orchestrator with in-built general purpose VNF Manager
-to deploy and operate Virtual Network Functions (VNFs).
- The provided deployment tool is experimental, not fault
-tolerant but as idempotent as possible. To use the provided shell
-script for provision/deployment, transfer the script to the Openstack
-primary controller node, where Your deployed OpenDaylight SDN
-controller runs. The deployment tool (poc.tacker-up.sh), expects that
-Your primary controller reaches all your OPNFV/Fuel cluster nodes and
-has internet connection either directly or via an http proxy, note
-that a working and consistent DNS name resolution is a must.
- Theory of operation: the deployment tool downloads the source
-python packages from GitHub and a json rpc library developed by Josh
-Marshall. Besides these sources, downloads software for python/debian
-software release. When building succeeds the script deploys the software
-components to the OPNFV Cluster nodes. Finally orchestrates the deployed
-tacker binaries as an infrastucture/service. The Tacker has two
-components:
-o Tacker server - what interacts with Openstack and OpenDayLight.
-o Tacker client - a command line software talks with the server,
- available on all cluster nodes and the access point
- to the Tacker service. Note that the tacker
- distribution provides a a plugin to the Horizon
- OpenStack Gui, but thus Horizon plugin is out of the
- scope of this Proof of Concept setup/deployment.
-As mentioned, this compilation contains an OpenDayLight SDN controller
-with Service Function Chaining and Group based Policy features enabled.
-
-To acces for your cluster information ssh to the fuel master (10.20.0.2)
-and issue command: fuel node.
-Here is an output of an example deployment:
-
-id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id
----|--------|------------------|---------|-----------|-------------------|----------------------------------|---------------|--------|---------
-3 | ready | Untitled (a2:4c) | 1 | 10.20.0.5 | 52:54:00:d3:a2:4c | compute | | True | 1
-4 | ready | Untitled (c7:d8) | 1 | 10.20.0.3 | 52:54:00:00:c7:d8 | cinder, controller, opendaylight | | True | 1
-1 | ready | Untitled (cc:51) | 1 | 10.20.0.6 | 52:54:00:1e:cc:51 | compute | | True | 1
-2 | ready | Untitled (e6:3e) | 1 | 10.20.0.4 | 52:54:00:0c:e6:3e | compute | | True | 1
-[root@fuel-sfc-virt ~]#
-
-As You can see in this case the poc.tacker-up.sh script should be
-transferred and run on node having IP address 10.20.0.3
diff --git a/prototypes/sfc_tacker/README.rst b/prototypes/sfc_tacker/README.rst
new file mode 100644
index 000000000..e219abd34
--- /dev/null
+++ b/prototypes/sfc_tacker/README.rst
@@ -0,0 +1,62 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+.. (c) 2016 Telefonaktiebolaget L. M. ERICSSON
+
+README SFC + Tacker
+===================
+
+The Enclosed shell script builds, deploys, orchestrates Tacker,
+an Open NFV Orchestrator with in-built general purpose VNF Manager
+to deploy and operate Virtual Network Functions (VNFs).
+
+The provided deployment tool is experimental, not fault
+tolerant but as idempotent as possible. To use the provided shell
+script for provision/deployment, transfer the script to the Openstack
+primary controller node, where Your deployed OpenDaylight SDN
+controller runs. The deployment tool (poc.tacker-up.sh), expects that
+Your primary controller reaches all your OPNFV/Fuel cluster nodes and
+has internet connection either directly or via an http proxy, note
+that a working and consistent DNS name resolution is a must.
+
+Theory of operation: the deployment tool downloads the source
+python packages from GitHub and a json rpc library developed by Josh
+Marshall. Besides these sources, downloads software for python/debian
+software release. When building succeeds the script deploys the software
+components to the OPNFV Cluster nodes. Finally orchestrates the deployed
+tacker binaries as an infrastucture/service. The Tacker has two
+components:
+
+#. Tacker server
+
+ - what interacts with Openstack and OpenDayLight.
+
+#. Tacker client
+
+ - a command line software talks with the server,
+ available on all cluster nodes and the access point
+ to the Tacker service. Note that the tacker
+ distribution provides a a plugin to the Horizon
+ OpenStack Gui, but thus Horizon plugin is out of the
+ scope of this Proof of Concept setup/deployment.
+
+As mentioned, this compilation contains an OpenDayLight SDN controller
+with Service Function Chaining and Group based Policy features enabled.
+
+To acces for your cluster information ssh to the fuel master (10.20.0.2)
+and issue command: fuel node.
+Here is an output of an example deployment:
+
++--------+------------+------------------+-------------+-----------+-------------------+----------------------------------+-------------------+------------+--------------+
+| **id** | **status** | **name** | **cluster** | **ip** | **mac** | **roles** | **pending_roles** | **online** | **group_id** |
++--------+------------+------------------+-------------+-----------+-------------------+----------------------------------+-------------------+------------+--------------+
+| 1 | ready | Untitled (cc:51) | 1 | 10.20.0.6 | 52:54:00:1e:cc:51 | compute | | True | 1 |
++--------+------------+------------------+-------------+-----------+-------------------+----------------------------------+-------------------+------------+--------------+
+| 2 | ready | Untitled (e6:3e) | 1 | 10.20.0.4 | 52:54:00:0c:e6:3e | compute | | True | 1 |
++--------+------------+------------------+-------------+-----------+-------------------+----------------------------------+-------------------+------------+--------------+
+| 3 | ready | Untitled (a2:4c) | 1 | 10.20.0.5 | 52:54:00:d3:a2:4c | compute | | True | 1 |
++--------+------------+------------------+-------------+-----------+-------------------+----------------------------------+-------------------+------------+--------------+
+| 4 | ready | Untitled (c7:d8) | 1 | 10.20.0.3 | 52:54:00:00:c7:d8 | cinder, controller, opendaylight | | True | 1 |
++--------+------------+------------------+-------------+-----------+-------------------+----------------------------------+-------------------+------------+--------------+
+
+As You can see in this case the poc.tacker-up.sh script should be
+transferred and run on node having IP address 10.20.0.3