Sorry, this lingered so long that I've lost context, so the comments
below may be a bit dumb. On the upside, I've heard surprisingly few
screams about its absence, so I feel we're a bit more free to think
about the approach a bit more.
https://codereview.appspot.com/14032043/diff/37001/state/state.go#newcode257
state/state.go:257: }
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?
(if we implemented lxc:X handling with a pseudo-provider maybe *that*
could be the bit responsible for container checking?)
Sorry, this lingered so long that I've lost context, so the comments
below may be a bit dumb. On the upside, I've heard surprisingly few
screams about its absence, so I feel we're a bit more free to think
about the approach a bit more.
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/
Remind me -- how does this work when the environ config is incomplete?
Don't we still need a state worker then?
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: }
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?
(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/