get_started:get_started_installer_approach
This is an old revision of the document!
Table of Contents
Base principles of the installation/deployment approach
Key objectives:
- Modular installation environment
- Agnostic to base installer of VM-Manager
Installer approach for BGS
The OPNFV install process consists of two main phases:
- BASE-INSTALLATION: Installation of plain-vanilla VM-manager (for BGS, OpenStack will be used as VM-Manager)
- (repeatable) install of a plain vanilla VM-manager (for BGS this is OpenStack) that deploys to bare metal and supports a HA-setup of the VM-manager
- the installation is performed with an installer "i" that creates a system in state BASE(i).
- Once the installation of the plain vanilla environment is complete, the installer i is terminated. The system is left in state BASE(i) and handed over to the second phase.
- OPNFV-INSTALLATION and MAINTENANCE: Installation of OPNFV specific modules, maintenance of the overall OPNFV installation
- the system state for this second phase is called OPNFV(x) - where x is determined by a particular OPNFV release item.
- install deltas to state BASE(i) to reach the desired state OPNFV(x). Deltas would be defined as a set of scripts/manifests. Given that the state BASE(i) differs by installer used, the scripts could also be different. That said, it is a clear objective to make these scripts as generic and independent from the installer used as possible.
- maintain the system in state OPNFV(x)
- decouple device configuration from orchestration; allow for different tool chains to be used for device configuration and orchestration. I.e. rather than couple device config and orchestration with a single tool such as puppet in master-agent mode, enable a single tool to be focused on config (e.g. puppet in master-less mode) and another one for orchestration (e.g. Ansible/Salt driving upgrade of components, download of particular manifests to the nodes etc.
Implementation status
The OPNFV BGS team currently conducts several parallel experiments to check the feasibility of the modular install approach. Individual components which define OPNFV(x) for the BGS context would ultimately align with the list of components listed on the wiki: https://wiki.opnfv.org/get_started/get_started_work_items.
Per BGS scope, the focus is on providing an installation to bare metal with HA and Ceph storage.
The following table supplies an overview of the experiments conducted currently (as of Feb 3, 2015):
| "Experiment" | #1 - "Foreman-Quickstack" | #2 "Fuel" | #3 "OpenSteak" | #4 "SlapStick" | #5 "Juju" |
|---|---|---|---|---|---|
| Base Installer | Foreman/QuickStack | Cobbler (packed up within Fuel 6) | maas | Ironic | Openstack-install |
| Local node config | Puppet (master/slave) | Fuel/Puppet | puppet (stackforge) + hiera | SaltStack | MAAS / JUJU |
| Orchestration | Khaleesi (Ansible framework) | bash/python scripts | SaltStack | JUJU | |
| OpenStack version | Juno | Juno | Juno | Icehouse, Juno | Icehouse, Juno |
| OpenDaylight version | Helium | Helium | Helium | Helium | Helium |
| Distro for compute nodes | Centos 7 | Centos 6.5 | Ubuntu 14.04 | Centos/RHEL 6.5/7, Ubuntu 12/14 | Ubuntu 14.04 LTS |
| Distro for Jumphost | Centos 7 | Ubuntu 14.04 | Linux | Ubuntu 14.04 LTS | |
| Congress/Copper Status | WIP | ||||
| Public deployment | Intel | Ericsson | Orange | Spirent | Juju |
| OPNFV Repo (common components) | |||||
| OPNFV Repo (non common components) | BGS Gerrit | BGS Gerrit | |||
| Non OPNFV References | Github | Github | |||
| Current Status | Foreman QuickStack Status | Fuel Status | OpenSteak Status | Being Defined | JuJu Status |
| Deployment Guide for OPNFV | Foreman/QuickStack Guide | Fuel Build and Deploy | JUJU Build and Deploy |
get_started/get_started_installer_approach.1426631675.txt.gz · Last modified: 2015/03/17 22:34 by Narinder Gupta
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
