Sharing a DB user password among units of the app

Stuart Bishop stuart.bishop at canonical.com
Mon Nov 4 09:50:26 UTC 2013


On Tue, Oct 29, 2013 at 7:38 PM, Andreas Hasenack <andreas at canonical.com> wrote:

> When the first unit of the app comes up, it creates a random password and
> uses the DB admin user to create an unprivileged DB user with that password.

Do you know why the client service needs to create the user, rather
than using users created by the PostgreSQL charm? Database roles can
be used to share permissions. Someone added support for roles in the
PostgreSQL charm a while back, but unfortunately neglected to document
the feature. Looking at db_relation_joined_changed() in
hooks/hooks.py, if your client sets the 'roles' relation attribute to
a comma separated list of role names, these roles are granted to the
generated user by the PostgreSQL charm. It also looks like there is a
bug here if you are using replication (slaves will attempt to grant
permissions and fail), but that looks to be an easy fix. Bug #1247767.

If you just need a well known username, then perhaps the PostgreSQL
charm should support that? It already allows the client to specify the
database name to use. I think this would solve the problem you detail
later in this thread with multiple services - if they all specify the
same username, they would then all get the same password (the
PostgreSQL service generated it, so it knows it).

> Now I run add-unit, and another unit comes up. How can it get that password?

> Is this a case for a peer relation?

As others have mentioned, this is where you need to use a peer
relationship to share the secret your service generated between that
service's units. If your service needs to share the secret to other
services, it will need a relation to those other services.

-- 
Stuart Bishop <stuart.bishop at canonical.com>



More information about the Juju mailing list