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#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?)
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 machine. go (right):
File cmd/jujud/
https:/ /codereview. appspot. com/14032043/ diff/37001/ cmd/jujud/ machine. go#newcode249 machine. go:249: environ, err := getStateEnviron(st)
cmd/jujud/
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 reasonable to allow container=lxc (which we *really* should
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/
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/