Sharing a DB user password among units of the app

[Stuart Bishop]

On 27 March 2014 19:13, Andreas Hasenack <andreas at canonical.com> wrote:
> On Thu, Mar 27, 2014 at 3:51 AM, Stuart Bishop
> <stuart.bishop at canonical.com> wrote:
>>> In effect it looks like I don't need to share the credentials among
>>> the services?
>>
>> Correct. I think you are just fine with one relation per database and
>> using the generated credentials, and using the granted roles to
>> control database permissions.
>
> I will have to try this in more detail. We already use the db-admin
> relation to do everything we need with the database, because that's
> how this is installed outside the world of juju. And that case still
> has to work, of course.
>
> One nag is that the db relation only gives me back one user, and
> certain versions of our product need two. These have different
> permissions. But I'll cross that bridge when I get to it.

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
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).


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