Can we get rid of the hash(password) dance?

roger peppe roger.peppe at canonical.com
Thu Jul 17 09:20:39 UTC 2014


Ah yes, of course, you are totally right.  It must go!
On 17 Jul 2014 10:17, "John Meinel" <john at arbash-meinel.com> wrote:

> ...
>
>
>> > From what I can tell poking around the code base, the only place that
>> still
>> > uses the hash(password) is actually in the Dummy provider.
>>
>> That's strictly true, but I don't think it helps. We only use ssh to
>> provision
>> machines at bootstrap time. The usual provisioning case still uses
>> cloudinit.
>> In this case, we don't use the hash(password) thing, but we *do* change
>> the password immediately when the agent starts, and we need to.
>> We *could* change the provisioner to provision machines synchronously,
>> but this would seem to me to add needless fragility to the system
>> (if the provisioner goes down while a machine is coming up, we'll
>> lose that machine).
>>
>> If changing the mongodb authorization information is a problem, can't
>> we just restart the agent when the password is changed?
>>
>
> So this isn't quite the same thing. Because this is changing your API
> password vs changing your DB password. IIRC machines that will be api
> servers (other than machine-0) actually use the API to set their password
> and then use the new password to initialize the database. Certainly we'll
> need to validate that assertion.
>
> And the problem we are running into is changing the *database* password
> because we want to use mgo.Session copying, which only remembers the
> initial password.
> I do think we can just reopen the database when we *do* have to change our
> password as long as we handle that early enough that we don't actually have
> another connection open somewhere else.
> John
> =:->
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140717/0439a33c/attachment.html>


More information about the Juju-dev mailing list