summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorTony Hansen <tony@att.com>2017-10-17 18:14:52 +0000
committerTony Hansen <tony@att.com>2017-10-17 18:20:57 +0000
commit8c55897ee1767e8a4577004e81889dbfc1005a94 (patch)
tree48086fa6e00a9af91dc3f6a05e09da2ba393b267
parent8a47174c6180efe4c6572222d97dda46189ce736 (diff)
addition PGaaS blueprint doc
Change-Id: I0409465dc6523fac81c8e89edaefc36e5b9feef3 Signed-off-by: Tony Hansen <tony@att.com> Issue-ID: DCAEGEN2-118
-rw-r--r--docs/sections/blueprints/PGaaS.rst29
1 files changed, 25 insertions, 4 deletions
diff --git a/docs/sections/blueprints/PGaaS.rst b/docs/sections/blueprints/PGaaS.rst
index 1b32d420..39d309f1 100644
--- a/docs/sections/blueprints/PGaaS.rst
+++ b/docs/sections/blueprints/PGaaS.rst
@@ -18,9 +18,30 @@ volumes matches the lifetime of the blueprint deployment. So when the
blueprint goes away, any Cinder storage volume allocated in the
blueprint also goes away.
-Similarly, a database's lifetime should have its
+Similarly, a database's lifetime may be the same time as an application's
+lifetime. When the application is undeployed, the associated database should
+be deployed too. OR, the database should have a lifetime beyond the scope
+of the applications that are writing to it or reading from it.
-The all-in-one blueprint assumes that everything can be allocated and
-deallocated together.
+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.
+
+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
+needed to access a given database on a given PostgreSQL cluster.
-MORE TO BE ADDED
+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
+to access the credentials.