Sharing a DB user password among units of the app

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


On Wed, Oct 30, 2013 at 4:58 AM, James Page <james.page at ubuntu.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

-k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131030/a26c5ca4/attachment.html>


More information about the Juju mailing list