Code review comment for lp://staging/~axwalk/juju-core/wire-up-prechecker

May want to hold off until synchronous bootstrap now, given the
oversight on getting an environ.

https://codereview.appspot.com/14032043/diff/37001/cmd/jujud/machine.go
File cmd/jujud/machine.go (right):

https://codereview.appspot.com/14032043/diff/37001/cmd/jujud/machine.go#newcode249
cmd/jujud/machine.go:249: environ, err := getStateEnviron(st)
On 2013/11/07 09:44:53, fwereade wrote:
> Remind me -- how does this work when the environ config is incomplete?
Don't we
> still need a state worker then?

Well, oops, I don't think it does work.

I must have coded this against a version of the manual provider that
couldn't have an incomplete config (there was a time when it had
defaults for everything).

This would change after synchronous bootstrap, since the agent will
never have an incomplete config. Doesn't work for now, though.

https://codereview.appspot.com/14032043/diff/37001/state/state.go
File state/state.go (right):

https://codereview.appspot.com/14032043/diff/37001/state/state.go#newcode257
state/state.go:257: }
On 2013/11/07 09:44:53, fwereade wrote:
> OK, Kapil's concerns are getting to me a little bit. Gut feeling: is
it
> sane/easy/reasonable to allow container=lxc (which we *really* should
name
> isolation=lxc) constraints to create unroutable containers, but to
restrict
> add-machine so it only allows addressable ones?

It's probably doable, but that sounds a bit hackish to me. I'd rather
just be explicit about requiring (at worst) an unroutable container.

> (if we implemented lxc:X handling with a pseudo-provider maybe *that*
could be
> the bit responsible for container checking?)

https://codereview.appspot.com/14032043/