path: root/docs/release/installation/upstream.rst
diff options
authorTim Rozet <>2018-11-09 11:17:28 -0500
committerTim Rozet <>2018-11-09 11:24:55 -0500
commitb188263699077102e956929970cc20191dafd312 (patch)
tree9aed230ef12422d3ed834202a216e28199aae86c /docs/release/installation/upstream.rst
parent1486696939e9b8d42f6f96bc5adb85849f675413 (diff)
Updates documentation for Gambia
Changes-Include: - Remove references to Apex ISO and disk image RPMs - Update supported scenarios - Update using upstream documentation Change-Id: If2b66d1d5a861bd1f90b0e8829de37d84e656619 Signed-off-by: Tim Rozet <>
Diffstat (limited to 'docs/release/installation/upstream.rst')
1 files changed, 17 insertions, 23 deletions
diff --git a/docs/release/installation/upstream.rst b/docs/release/installation/upstream.rst
index b98b0c1..f18c4b1 100644
--- a/docs/release/installation/upstream.rst
+++ b/docs/release/installation/upstream.rst
@@ -1,14 +1,11 @@
-Deploying Directly from Upstream - (Beta)
+Deploying Directly from Upstream
-In addition to deploying with OPNFV tested artifacts included in the
-opnfv-apex-undercloud and opnfv-apex RPMs, it is now possible to deploy
+When installing the Undercloud and Overcloud, the disk images are now downloaded
directly from upstream artifacts. Essentially this deployment pulls the latest
RDO overcloud and undercloud artifacts at deploy time. This option is useful
-for being able to deploy newer versions of OpenStack that are not included
-with this release, and offers some significant advantages for some users.
-Please note this feature is currently in beta for the Fraser release and will
-be fully supported in the next OPNFV release.
+for being able to pull the latest Queens and other OPNFV components which have
+been promoted via a TripleO pipeline and deemed to be stable.
Upstream Deployment Key Features
@@ -39,19 +36,15 @@ in order to download and prepare the cached artifacts.
Scenarios and Deploy Settings for Upstream Deployments
-Some deploy settings files are already provided which have been tested by the
-Apex team. These include (under /etc/opnfv-apex/):
- - os-nosdn-queens_upstream-noha.yaml
- - os-nosdn-master_upstream-noha.yaml
- - os-odl-queens_upstream-noha.yaml
- - os-odl-master_upstream-noha.yaml
-Each of these scenarios has been tested by Apex over the Fraser release, but
-none are guaranteed to work as upstream is a moving target and this feature is
-relatively new. Still it is the goal of the Apex team to provide support
-and move to an upstream based deployments in the future, so please file a bug
-when encountering any issues.
+The deploy settings and scenarios included with the Gambia release of Apex will
+be supported as deemed by the `OPNFV Scenarios in Apex`_ section of this guide.
+Each of these scenarios has been tested by Apex over the Gambia release, and
+using those deploy settings will control which upstream artifacts are pulled
+at deploy time. By specifying different versions of OpenStack, ODL, or other
+components in the deploy settings, different upstream artifacts may be downloaded
+and are not considered to be supported. For deploying newer versions of components
+it is advised to use the master branch of OPNFV Apex as part of our continuous
+integration effort to support those components.
Including Upstream Patches with Deployment
@@ -83,8 +76,7 @@ Running ``opnfv-deploy``
Deploying is similar to the typical method used for baremetal and virtual
deployments with the addition of a few new arguments to the ``opnfv-deploy``
-command. In order to use an upstream deployment, please use the ``--upstream``
-argument. Also, the artifacts for each upstream deployment are only
+command. The artifacts for each upstream deployment are only
downloaded when a newer version is detected upstream. In order to explicitly
disable downloading new artifacts from upstream if previous artifacts are
already cached, please use the ``--no-fetch`` argument.
@@ -105,3 +97,5 @@ container with a bash shell. Note the containers do not use systemd, unlike
the traditional deployment model and are instead started as the first process
in the container. To restart a service, use the ``docker restart <container>``
+.. _`OPNFV Scenarios in Apex`: architecture.html#opnfv-scenarios-in-apex