On Tue, Oct 29, 2013 at 7:38 PM, Andreas Hasenack <[email protected]> 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 <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
