Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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). The installer has its own (typically upstream) repository that OPNFV leverages. (If the installer resides in an upstream repo, forking into an OPNFV repo is strongly discouraged).
    * 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 conducts several parallel experiments to check the feasibility of the modular install approach.
Individual components which define OPNFV(Release 1) for the BGS context will align with the list of components listed on the wiki: https://wiki.opnfv.org/get_started/get_started_work_items.

The "OPNFV-INSTALLATION and MAINTENANCE" phase of the installation is agnostic to the base installer used. Components for the "OPNFV-INSTALLATION and MAINTENANCE" phase are common across all installers. These common components are found in the: [[https://gerrit.opnfv.org/gerrit/gitweb?p=genesis.git;a=tree;f=common;h=3d993ab7aed4543389d87fca26950437fb7f103e;hb=HEAD|common part of the genesis repository]].

Note: The table which compares different installer approaches which was originally found here has been moved to a dedicated wiki page: [[get_started:installers|List of current deployment tools (installers) investigated]]
Wiki

User Tools

Site Tools

Page Tools
