diff options
| -rw-r--r-- | docs/sections/blueprints/PGaaS.rst | 31 |
1 files changed, 18 insertions, 13 deletions
diff --git a/docs/sections/blueprints/PGaaS.rst b/docs/sections/blueprints/PGaaS.rst index 2d20b047..080e5757 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 @@ Blueprint Files 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 ^^^^^^^^^^^^ |