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.
-k On Tue, Oct 29, 2013 at 9:55 AM, Andreas Hasenack <[email protected]>wrote: > On Tue, Oct 29, 2013 at 11:11 AM, John Arbash Meinel < > [email protected]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 2013-10-29 16:38, Andreas Hasenack wrote: >> > Now I run add-unit, and another unit comes up. How can it get that >> > password? >> > >> ... >> > >> > Is this a case for a peer relation? >> > >> > >> >> Yes. As I understand it, that is exactly what a peer relation is for. >> >> > Turns out a peer relation won't be good enough. It solves the add-unit > case, sure, but I also need to share this password among different > *services* (I neglected to consider that at first). > > In this case the application is composed of several different services > that talk to the DB. So while I can scale out the units of a service and > have the password shared among those units, there is no way that I can see > where I can also share those credentials with the other services that make > up my application. > > I'll take the config approach for now and make sure all services are > deployed with the same initially-chosen-by-the-admin password. > > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
