LGTM; I do find all this stuff a bit tricky to follow, though, and I
feel like there's a simpler model waiting to come out. Let's wait and
see if one emerges when we're actually using the API.


https://codereview.appspot.com/9738043/diff/5001/cmd/jujud/bootstrap.go
File cmd/jujud/bootstrap.go (right):

https://codereview.appspot.com/9738043/diff/5001/cmd/jujud/bootstrap.go#newcode140
cmd/jujud/bootstrap.go:140: }
On 2013/06/07 17:01:55, rog wrote:
> On 2013/05/27 20:13:26, fwereade wrote:
> > I guess if we fail here, we have a borked environment regardless.
So, given
> the
> > failure modes we've already embraced, ok, I guess... but it's a bit
surprising
> > nonetheless. Comment perhaps?

> i'm not sure what kind of comment you're thinking here.
> how is failing to write the configuration any different
> from any of the above failure modes?

Yeah, I guess it's no different; this is just the latest expression of
my paranoia that one-shotting bootstrap, rather than ensuring it
actually completes, will cause us surprising and upsetting problems one
day. No action needed here.

https://codereview.appspot.com/9738043/diff/5001/cmd/jujud/bootstrap_test.go
File cmd/jujud/bootstrap_test.go (right):

https://codereview.appspot.com/9738043/diff/5001/cmd/jujud/bootstrap_test.go#newcode198
cmd/jujud/bootstrap_test.go:198: info.Tag, info.Password = "",
testPasswordHash
On 2013/06/07 17:01:55, rog wrote:
> On 2013/05/27 20:13:26, fwereade wrote:
> > wait, why can user-admin log in as ""?

> the empty string means "admin" when logging into the state. see the
docs on
> state.Info.Tag. i disclaim all responsibility for that decision :-)

ok, thanks for pointing that out

https://codereview.appspot.com/9738043/diff/5001/cmd/jujud/bootstrap_test.go#newcode220
cmd/jujud/bootstrap_test.go:220:
c.Assert(machineConf1.StateInfo.Password, Equals,
machineConf1.APIInfo.Password)
On 2013/06/07 17:01:55, rog wrote:
> On 2013/05/27 20:13:26, fwereade wrote:
> > Are we duplicating tag/password for the same entities everywhere? If
so, why?

> we use the same password for the state that we do for the API.
> is that bad?

I reserve judgment on that; I think it smells a little bit, because API
access is a very different thing to state access... but I'm more
thinking that the *.Info types are feeling a bit overloaded, and that --
if the two chunks of data are fundamentally the same rather than just
coincidentally so -- separating that common auth data is probably a
pretty good idea.

Really, I was just looking for clarification.

https://codereview.appspot.com/9738043/diff/5001/environs/agent/agent.go
File environs/agent/agent.go (right):

https://codereview.appspot.com/9738043/diff/5001/environs/agent/agent.go#newcode208
environs/agent/agent.go:208: func (c *Conf) OpenAPI() (st *api.State,
newPassword string, err error) {
On 2013/06/07 17:01:55, rog wrote:
> On 2013/05/27 20:13:26, fwereade wrote:
> > Why are we duplicating this back-to-front newPassword-juggling
behaviour?

> what do you suggest instead? we still need to do exactly the same
thing AFAICS.
> i wasn't thinking of redesigning this logic at this point, but i can
do if you'd
> like it to change.

Not worth making speculative effort, I suppose. But I always found that
bit demanded a surprising amount of concentration, and was vaguely
hoping something leaner might emerge.

https://codereview.appspot.com/9738043/