add doc on single-vm pgaas configuration
Change-Id: I9c1c619d68fa2ef4f38619b9e0ed64c2601d70b6
Signed-off-by: Tony Hansen <tony@att.com>
Issue-ID: DCAEGEN2-185
diff --git a/docs/sections/blueprints/PGaaS.rst b/docs/sections/blueprints/PGaaS.rst
index 2d20b04..080e575 100644
--- a/docs/sections/blueprints/PGaaS.rst
+++ b/docs/sections/blueprints/PGaaS.rst
@@ -1,15 +1,15 @@
PostgreSQL as a Service
============
-PostgreSQL as a Service comes in two flavors: all-in-one blueprint, and
+PostgreSQL as a Service (PGaaS) comes in two flavors: all-in-one blueprint, and
separate disk/cluster/database blueprints to separate the management of
the lifetime of those constituent parts. Both are provided for use.
-Why Two Flavors?
+Why Three Flavors?
------------
-The reason there are two flavors of blueprints lays in the difference in
-lifetime management of the constituent parts.
+The reason there are three flavors of blueprints lays in the difference in
+lifetime management of the constituent parts and the number of VMs created.
For example, a database usually needs to have persistent storage, which
in these blueprints comes from Cinder storage volumes. The primitives
@@ -29,26 +29,31 @@
The Blueprints for PG Services and Cinder
^^^^^^^^^^^
-The all-in-one blueprint PGaaS.yaml assumes that the PG servers and Cinder volumes can be allocated and
-deallocated together. This PGaaS.yaml blueprint creates a cluster named "pstg" by default.
+The all-in-one blueprint ``pgaas.yaml`` assumes that the PG servers and Cinder volumes can be allocated and
+deallocated together. The ``pgaas.yaml`` blueprint creates a cluster of two VMs named "``pstg``" by default.
-Alternatively, you can split them apart into separate steps, using PGaaS-disk.yaml to allocate the
-Cinder volume, and PGaaS-cluster.yaml to allocate a PG cluster. Create the Cinder volume first using
-PGaaS-disk.yaml, and then use PGaaS-cluster.yaml to create the cluster. The PG cluster can be
+The ``pgaas-onevm.yaml`` blueprint creates a single-VM instance named "``pgvm``" by default.
+
+Alternatively, you can split them apart into separate steps, using ``pgaas-disk.yaml`` to allocate the
+Cinder volume, and ``pgaas-cluster.yaml`` to allocate a PG cluster. Create the Cinder volume first using
+``pgaas-disk.yaml``, and then use ``pgaas-cluster.yaml`` to create the cluster. The PG cluster can be
redeployed without affecting the data on the Cinder volumes.
The Blueprints for Databases
^^^^^^^^^^^
-The PGaaS-database.yaml blueprint shows how a database can be created separately from any application
-that uses it. That database will remain present until the PGaaS-database.yaml blueprint is
-undeployed. The PGaaS-getdbinfo.yaml file demonstrates how an application would access the credentials
+The ``pgaas-database.yaml`` blueprint shows how a database can be created separately from any application
+that uses it. That database will remain present until the pgaas-database.yaml blueprint is
+undeployed. The ``pgaas-getdbinfo.yaml`` file demonstrates how an application would access the credentials
needed to access a given database on a given PostgreSQL cluster.
If the lifetime of your database is tied to the lifetime of your application, use a block similar to what
-is in PGaaS-database.yaml to allocate the database, and use the attributes as shown in PGaaS-getdbinfo.yaml
+is in ``pgaas-database.yaml`` to allocate the database, and use the attributes as shown in ``pgaas-getdbinfo.yaml``
to access the credentials.
+Both of these blueprints use the ``dcae.nodes.pgaas.database`` plugin reference, but ``pgaas-getdbinfo.yaml``
+adds the ``use_existing: true`` property.
+
What is Created by the Blueprints
^^^^^^^^^^^^