Merge lp://staging/~stub/charms/precise/postgresql/bug-1276024-fix-log-shipping into lp://staging/charms/postgresql
| Status: | Merged |
|---|---|
| Merge reported by: | Marco Ceppi |
| Merged at revision: | not available |
| Proposed branch: | lp://staging/~stub/charms/precise/postgresql/bug-1276024-fix-log-shipping |
| Merge into: | lp://staging/charms/postgresql |
| Prerequisite: | lp://staging/~stub/charms/precise/postgresql/bug-1281600-log_temp_files |
| Diff against target: |
333 lines (+167/-30) 5 files modified
config.yaml (+6/-3) hooks/hooks.py (+89/-9) templates/postgres.cron.tmpl (+9/-12) templates/swiftwal.conf.tmpl (+5/-5) test.py (+58/-1) |
| To merge this branch: | bzr merge lp://staging/~stub/charms/precise/postgresql/bug-1276024-fix-log-shipping |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| charmers | Pending | ||
|
Review via email:
|
|||
Description of the change
Wire up the STILL EXPERIMENTAL Swift log shipping, per Bug #1276024.
SwiftWAL is a tool I wrote to allow PostgreSQL to push filesystem level
backups and log ship WAL files to Swift. It is similar to WAL-E. In fact,
it is so similar that I will probably scrap it in favor of WAL-E since
WAL-E now supports Swift in addition to Amazon S3. Switching to or adding
support for WAL-E should be mostly mechanical work, although IIRC it
still needed bidirectional SSH setup too.
Anyway, back to the branch at hand, this branch is concerned with log
shipping to Swift. Log shipping is one component of configuring point
in time recovery, and allows us to replicate without a streaming
replication connection.
This branch also fixes up filesystem backups to Swift, but finalizing
backups, recovery and tests is for a later branch and may require juju
actions to be implemented first.
I'm keeping the EXPERIMENTAL status since I'm expecting changes to the
design. For instance, should all the OpenStack configuration be in the
config, or should be be creating a relation to some service to retrieve
the credentials? Or perhaps we need a generic object storage service that
proxies to the provider's object storage system? It would be great if I
could write this once and have it work on all providers.
The Swift tests are skipped unless a valid set of OpenStack credentials
are found in the environment (OS_TENANT_NAME, OS_AUTH_URL etc.).
| Charles Butler (lazypower) wrote | # |
| Stuart Bishop (stub) wrote | # |
| Stuart Bishop (stub) wrote | # |
| Whit Morriss (whitmo) wrote | # |
Stub,
I've taken a look through this, and with you openly stating its a stop gap prior to Wal-E, do we want to pursue this branch in leu of that integration? Or would it be prudent to pin this and review when WAL-E lands?
I'm not seeing anything terribly heinous in this, but I also haven't run deployment tests on it as of yet.