Merge ~cjwatson/launchpad:db-roles into launchpad:master
Status: | Merged |
---|---|
Approved by: | Colin Watson |
Approved revision: | 31b283765f2cb0c3c6551c46c02dd84cd51b505e |
Merge reported by: | Otto Co-Pilot |
Merged at revision: | not available |
Proposed branch: | ~cjwatson/launchpad:db-roles |
Merge into: | launchpad:master |
Diff against target: |
234 lines (+122/-14) 4 files modified
lib/lp/services/config/__init__.py (+1/-0) lib/lp/services/config/schema-lazr.conf (+7/-0) lib/lp/services/webapp/adapter.py (+16/-5) lib/lp/services/webapp/tests/test_adapter.py (+98/-9) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Andrey Fedoseev (community) | Approve | ||
Review via email: mp+432027@code.launchpad.net |
Commit message
Add ability to switch DB role after connecting
Description of the change
Our traditional strategy for deploying database credentials has been to have a password for each database user we want to use, and to deploy those to `.pgpass` files on each machine that needs to use each user. This works, but it's quite manual and cumbersome. With charmed deployments it gets harder: each `db` relation can only communicate a single set of credentials, which means that a script server would be stuck having to have perhaps tens of relations representing the wide variety of database users that the scripts it runs want to use: as well as being ugly, I expect this would also make Juju very slow.
The natural approach with the PostgreSQL charm (or when emulating it using `external-
I don't see a straightforward way to make these two strategies entirely compatible, but it's simple enough to add a configuration flag that selects which strategy we're using, so I've taken that approach. `database.