| Lusheng Ji | bd11574 | 2017-10-13 19:18:52 +0000 | [diff] [blame] | 1 | PostgreSQL as a Service |
| 2 | ============ |
| Tony Hansen | 30c453e | 2017-10-13 14:34:46 +0000 | [diff] [blame] | 3 | |
| 4 | PostgreSQL as a Service comes in two flavors: all-in-one blueprint, and |
| 5 | separate disk/cluster/database blueprints to separate the management of |
| 6 | the lifetime of those constituent parts. Both are provided for use. |
| 7 | |
| Lusheng Ji | bd11574 | 2017-10-13 19:18:52 +0000 | [diff] [blame] | 8 | Why Two Flavors? |
| 9 | ------------ |
| Tony Hansen | 30c453e | 2017-10-13 14:34:46 +0000 | [diff] [blame] | 10 | |
| 11 | The reason there are two flavors of blueprints lays in the difference in |
| 12 | lifetime management of the constituent parts. |
| 13 | |
| 14 | For example, a database usually needs to have persistent storage, which |
| 15 | in these blueprints comes from Cinder storage volumes. The primitives |
| 16 | used in these blueprints assume that the lifetime of the Cinder storage |
| 17 | volumes matches the lifetime of the blueprint deployment. So when the |
| 18 | blueprint goes away, any Cinder storage volume allocated in the |
| 19 | blueprint also goes away. |
| 20 | |
| 21 | Similarly, a database's lifetime should have its |
| 22 | |
| 23 | The all-in-one blueprint assumes that everything can be allocated and |
| 24 | deallocated together. |
| 25 | |
| 26 | MORE TO BE ADDED |