summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorVijay Venkatesh Kumar <vv770d@att.com>2017-10-17 18:42:22 +0000
committerGerrit Code Review <gerrit@onap.org>2017-10-17 18:42:22 +0000
commit1294948a8a45aaf48f642cddd0950900f9e20cf2 (patch)
tree4fdefac9da4efa5a03055437f6aa216feb6c281f
parent776ddf57b83d5c70912d68c2902ae64097209156 (diff)
parent8c55897ee1767e8a4577004e81889dbfc1005a94 (diff)
Merge "addition PGaaS blueprint doc"
-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.