A simple method to separate configuration for base fuel, plugins, PODs

and deployment/test scenarios

READY TO MERGE!

Replaces: https://gerrit.opnfv.org/gerrit/#/c/3995/

Abstract
--------
This deployment framework relies on a configuration structure,
providing base installer configuration, per POD specific configuration,
plugin configuration, and deployment scenario configuration.
- 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.
- Plugin configuration - providing configuration of a specific plugin.
  these configurations maintain there own namespace and are normally maintained
  by collaborative projects building Fuel@OPNFV plugins
- Deployment scenario configuration - provides a high level, POD/HW environment
  independent scenario configuration for a specific deployment. It defines what
  features/plugins that shall be deployed - as well needed overrides of the
  plugin config as well as the base installer-, POD/HW environment-
  configurations. Objects allowed to override
  is governed by the Fuel@OPNFV project.

Executing a deployment
----------------------
deploy.sh must be executed locally at the target lab/pod/jumpserver
A lab 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 ericsson-1 -p pod-2
-s os_odl-l2_no-ha -i file:///home/jenkins/MyIso.iso

-b and -i arguments should be expressed in URI style. The resources can thus be
local or remote.

Feedback
--------
Please give feed-back before I'm going to far on a wrong tangent

Implemented scenarios so far:
-----------------------------
- os_ha
- os_no-ha
- os_odl-l3_ha
- os_odl-l3_no-ha
- os_odl-l2_ha
- os_odl-l2_no-ha
- os_onos_ha
- os_onos_no-ha
- os_kvm_ha
- os_kvm_no-ha
- os_ovs_ha
- os_ovs_no-ha
- os_kvm_ovs_ha
- os_kvm_ovs_no-ha

VERIFIED
READY TO MERGE

JIRA: FUEL-35

Change-Id: I94a9b477d8ed4ee8057c16d8f20fe543f7ecc20d
Signed-off-by: Jonas Bjurel <jonas.bjurel@ericsson.com>

1 files changed, 165 insertions, 0 deletions

diff --git a/deploy/scenario/README b/deploy/scenario/README
new file mode 100644
index 000000000..aebeb40ee
--- /dev/null
+++ b/deploy/scenario/README
@@ -0,0 +1,165 @@
+##############################################################################
+# Copyright (c) 2015 Ericsson AB and others.
+# 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
+##############################################################################
+
+Abstract:
+---------
+The directory contains configuration files for different OPNFV deployment
+feature scenarios used by Fuel@OPNFV, eg.:
+- High availability configuration
+- Type of SDN controller to be deployed
+- OPNFV collaboration project features to be deployed.
+- Provisioning of any other sevices
+
+Creating a new plugin
+---------------------
+Creating a new plugin involves creating a plugin config yaml file in
+/deploy/config/plugins. The filename should comply to following structure:
+fuel-<plugin_name>_<version>.yaml.
+The plugin configuration must include plugin configuration metadata as below:
+
+plugin-config-metadata:
+  title:
+  version:
+  created:
+  comment:
+
+Moreover, naturaly the plugin configuration must include the plugin yaml
+fragment, eg:
+
+opendaylight:
+  metadata:
+    enabled: true
+    label: OpenDaylight Lithium plugin
+.......
+
+Creating a new deployment scenario
+----------------------------------
+Creating a new deployment scenario involve creating a deployment scenario
+yaml file under deploy/scenario/. The filename should comply to following
+format: <ha | no-ha>_<SDN Controller>_<feature-1>_..._<feature-n>_<version>.yaml
+
+The deployment configuration file must contain configuration metadata as stated
+below:
+
+deployment-scenario-metadata:
+   title:
+   version:
+   created:
+   comment:
+
+To include fuel plugins, use the stack-extentions key:
+stack-extensions, eg:
+
+stack-extensions:
+   - module: opendaylight
+     module-config-name: fuel-odl
+     module-config-version: 0.0.1
+     module-config-override:
+       # Module config overrides
+       rest_api_port:
+         value: '8282'
+       enable_gbp:
+         value: false
+       enable_l3_odl:
+         value: true
+       enable_sfc:
+         value: false
+
+"module-config-name" and "module-config-version" must correspond to how
+the plugin configuration yaml was named.
+Everything under the "module-config-override" overrides the corresponding
+keys in the plugin config yaml file, this can for instance be used to configure
+the plugin.
+
+Everything under the "dea-override-config" overrides corresponding keys in the dea_base.yaml and dea_pod_override.yaml.
+You must at least provide {environment:{mode:'value},{net_segment_type:'value'}
+and {nodes:....} in order to configure the HA mode, network segmentation types
+and role to node assignments.
+Other ovverides may also be used to enable stack features such as ceph, heat,
+etc.
+Example:
+
+dea-override-config:
+  environment:
+    mode: ha
+    net_segment_type: tun
+  wanted_release: Kilo on Ubuntu 14.04
+  nodes:
+  - id: 1
+    interfaces: interfaces_1
+    role: mongo,controller,opendaylight
+    transformations: transformations_1
+  - id: 2
+    interfaces: interfaces_1
+    role: mongo,controller
+    transformations: transformations_1
+  - id: 3
+    interfaces: interfaces_1
+    role: mongo,controller
+    transformations: transformations_1
+  - id: 4
+    interfaces: interfaces_1
+    role: ceph-osd,compute
+    transformations: transformations_1
+  - id: 5
+    interfaces: interfaces_1
+    role: ceph-osd,compute
+    transformations: transformations_1
+
+  settings:
+    editable:
+      additional_components:
+        ceilometer:
+          description: If selected, Ceilometer component will be installed
+          label: Install Ceilometer
+          type: checkbox
+          value: true
+          weight: 40
+        heat:
+          description: ''
+          label: ''
+          type: hidden
+          value: true
+          weight: 30
+        metadata:
+          label: Additional Components
+          weight: 20
+      storage:
+        ephemeral_ceph:
+          description: Configures Nova to store ephemeral volumes in RBD. This works
+            best if Ceph is enabled for volumes and images, too. Enables live migration
+            of all types of Ceph backed VMs (without this option, live migration will
+            only work with VMs launched from Cinder volumes).
+          label: Ceph RBD for ephemeral volumes (Nova)
+          type: checkbox
+          value: true
+          weight: 75
+        images_ceph:
+          description: Configures Glance to use the Ceph RBD backend to store images.
+            If enabled, this option will prevent Swift from installing.
+          label: Ceph RBD for images (Glance)
+          restrictions:
+          - settings:storage.images_vcenter.value == true: Only one Glance backend could
+              be selected.
+          type: checkbox
+          value: true
+          weight: 30
+
+Optionally you may override the pod dha defenition under the
+"dha-override-config" key.
+
+Short names
+-----------
+scenario.yaml provides a mapping between a deployment scenario short-name
+and one or several deployment scenario configuration yaml files.
+
+Other
+-----
+These configuration files are used by deploy.sh provided by Fuel@OPNFV, e.g.
+deploy.sh will clone this repo when deploying.
\ No newline at end of file