docs/release/installation/upstream.rst

   1 Deploying Directly from Upstream
   2 ================================
   3
   4 When installing the Undercloud and Overcloud, the disk images are now downloaded
   5 directly from upstream artifacts.  Essentially this deployment pulls the latest
   6 RDO overcloud and undercloud artifacts at deploy time.  This option is useful
   7 for being able to pull the latest Queens and other OPNFV components which have
   8 been promoted via a TripleO pipeline and deemed to be stable.
   9
  10 Upstream Deployment Key Features
  11 --------------------------------
  12
  13 In addition to being able to install newer versions of OpenStack, the upstream
  14 deployment option allows the use of a newer version of TripleO, which provides
  15 overcloud container support.  Therefore when deploying from upstream with an
  16 OpenStack version newer than Pike, every OpenStack service (also OpenDaylight)
  17 will be running as a docker container.  Furthermore, deploying upstream gives
  18 the user the flexibility of including any upstream OpenStack patches he/she
  19 may need by simply adding them into the deploy settings file.  The patches will
  20 be applied live during deployment.
  21
  22 Installation Guide - Upstream Deployment
  23 ========================================
  24
  25 This section goes step-by-step on how to correctly install and provision the
  26 OPNFV target system using a direct upstream deployment.
  27
  28 Special Requirements for Upstream Deployments
  29 ---------------------------------------------
  30
  31 With upstream deployments it is required to have internet access.  In addition,
  32 the upstream artifacts will be cached under the root partition of the jump
  33 host.  It is required to at least have 10GB free space in the root partition
  34 in order to download and prepare the cached artifacts.
  35
  36 Scenarios and Deploy Settings for Upstream Deployments
  37 ------------------------------------------------------
  38
  39 The deploy settings and scenarios included with the Gambia release of Apex will
  40 be supported as deemed by the `OPNFV Scenarios in Apex`_ section of this guide.
  41 Each of these scenarios has been tested by Apex over the Gambia release, and
  42 using those deploy settings will control which upstream artifacts are pulled
  43 at deploy time. By specifying different versions of OpenStack, ODL, or other
  44 components in the deploy settings, different upstream artifacts may be downloaded
  45 and are not considered to be supported. For deploying newer versions of components
  46 it is advised to use the master branch of OPNFV Apex as part of our continuous
  47 integration effort to support those components.
  48
  49 Including Upstream Patches with Deployment
  50 ------------------------------------------------------
  51
  52 With upstream deployments it is possible to include any pending patch in
  53 OpenStack gerrit with the deployment.  These patches are applicable to either
  54 the undercloud or the overcloud.  This feature is useful in the case where
  55 a developer or user desires to pull in an unmerged patch for testing with a
  56 deployment.  In order to use this feature, include the following in the deploy
  57 settings file, under "global_params" section:
  58
  59 .. code-block:: yaml
  60
  61      patches:
  62        undercloud:
  63          - change-id: <gerrit change id>
  64            project: openstack/<project name>
  65            branch:  <branch where commit is proposed>
  66        overcloud:
  67          - change-id: <gerrit change id>
  68            project: openstack/<project name>
  69            branch:  <branch where commit is proposed>
  70
  71 You may include as many patches as needed.  If the patch is already merged or
  72 abandoned, then it will not be included in the deployment.
  73
  74 Running ``opnfv-deploy``
  75 ------------------------
  76
  77 Deploying is similar to the typical method used for baremetal and virtual
  78 deployments with the addition of a few new arguments to the ``opnfv-deploy``
  79 command. The artifacts for each upstream deployment are only
  80 downloaded when a newer version is detected upstream.  In order to explicitly
  81 disable downloading new artifacts from upstream if previous artifacts are
  82 already cached, please use the ``--no-fetch`` argument.
  83
  84 Interacting with Containerized Overcloud
  85 ----------------------------------------
  86
  87 Upstream deployments will use a containerized overcloud.  These containers are
  88 Docker images built by the Kolla project.  The Containers themselves are run
  89 and controlled through Docker as root user.  In order to access logs for each
  90 service, examine the '/var/log/containers' directory or use the `docker logs
  91 <container name>`.  To see a list of services running on the node, use the
  92 ``docker ps`` command.  Each container uses host networking, which means that
  93 the networking of the overcloud node will act the same exact way as a
  94 traditional deployment.  In order to attach to a container, use this command:
  95 ``docker exec -it <container name/id> bin/bash``.  This will login to the
  96 container with a bash shell.  Note the containers do not use systemd, unlike
  97 the traditional deployment model and are instead started as the first process
  98 in the container.  To restart a service, use the ``docker restart <container>``
  99 command.
 100
 101 .. _`OPNFV Scenarios in Apex`: architecture.html#opnfv-scenarios-in-apex