<div dir="ltr">On Tue, Oct 29, 2013 at 11:11 AM, John Arbash Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div class="im"><br>
On 2013-10-29 16:38, Andreas Hasenack wrote:<br>> Now I run add-unit, and another unit comes up. How can it get that<br>
> password?<br>
><br>
</div>...<br>
<div class="im">><br>
> Is this a case for a peer relation?<br>
><br>
><br>
<br>
</div>Yes. As I understand it, that is exactly what a peer relation is for.<br>
<br></blockquote><div><br></div><div>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).</div>

<div><br></div><div>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.</div>

<div><br></div><div>I'll take the config approach for now and make sure all services are deployed with the same initially-chosen-by-the-admin password.</div><div><br></div></div></div></div>