Sharing a DB user password among units of the app

Kapil Thangavelu kapil.thangavelu at
Wed Oct 30 14:35:01 UTC 2013

On Wed, Oct 30, 2013 at 4:58 AM, James Page < at> wrote:

> Hash: SHA256
> On 29/10/13 17:12, Kapil Thangavelu wrote:
> > fwiw, the mysql charm tries to address this with a shared-db
> > interface, and a separate admin interface. ie the shared-db
> > interface shares out the same db user/password to multiple
> > services, and then for things that need admin access they can be
> > related to the admin interface.
> Right now the username/passwords are stored on the disk that the mysql
> datafiles reside on; currently in a clustered mysql with ceph backing
> volume this is always presented to the active mysql node so should be
> up-to-date.  Only the active node will dish out requests for passwords
> from related services.
> This won't work when we move to active/active mysql; in this case we
> will probably use the approach in the keystone charm where
> username/passwords are stored on local disk and synced out to peered
> service units via a unpriviledged SSH account and unison.

Just thinking outloud, but In the active-active db scenario, there's an
available db for the charm to store this info. ie. the charm could keep
some bookeeping tables/db instead of using files on disk (a shared key via
peer relation used for storing the credentials in db).

> Unless, of course, Juju grows a feature to allow peers to share data
> in a way which is more consistent that trying todo it via the peer
> relation.
The leader election cli api would hopefully resolve this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Juju mailing list