Sharing a DB user password among units of the app

[Andreas Hasenack]

On Thu, Mar 27, 2014 at 11:37 AM, Stuart Bishop
<stuart.bishop at canonical.com> wrote:
> I've just looked at the code, and if you are using a db-admin relation
> you can already connect to any database as any user. You can connect
> using the credentials you are given and create the additional users
> you need in the db-admin-relation-changed hook. If you use the same
> password as the generated user, you won't even have to worry about
> distributing that information between units in the relation.
>
>> Here I would need one "db" relation just to get the roles. I wouldn't
>> create the 6 databases here (how could I?), I would let the existing
>> code (not charm code: product code) do that as usual. Let's see how
>> far I get.
>
> If you need 6 databases, you could add 6 relations to the PostgreSQL
> service each specifying a different database name. Your charm wouldn't
> care if these are 6 relations to a single PostgreSQL service, 6
> relations to 6 separate PostgreSQL services, or something in between.
> If that is too mach deployment hassle, then you can do this with a

That seems too much hassle indeed.

Let me take a step back: this all started because I wanted the
deployment to use randomly generated passwords for the database users.

That seems a perfectly reasonable requirement, and not doing that
leads to a wtf moment even. I mean, exposing the internal database
user passwords in the charm config and expecting the admin to change
that with every deployment doesn't work.

> single db-admin relation and issue the CREATE DATABASE commands in
> your db-admin-relation-changed hook. Let me know if you end up
> manually creating databases - I should ensure that the backup jobs
> cope (everything else should be just fine, including replication).

We do that. The databases are created in the db-admin-relation-changed
hook, using the superuser that said relation gave us when it was
established. This hook also, today, creates the database user (role
with LOGIN), and sets a password for it. Due to all these histerical
reasons ;) from this thread, this breaks if the password is randomly
generated locally.