lxd provider fails to cleanup on failed bootstrap

[Tim Penhey]

$ juju bootstrap --debug
...
Attempt 1 to download tools from https://streams.canonical.com/juju/tools/devel/juju-1.26-alpha1-trusty-amd64.tgz...
tools from https://streams.canonical.com/juju/tools/devel/juju-1.26-alpha1-trusty-amd64.tgz downloaded: HTTP 200; time 24.512s; size 18804733 bytes; speed 767153.000 bytes/s Tools downloaded successfully.
31d31dd99ba3dd7bbb0671911d9c8fdf4f63e559b7726368c92f3ea76d3231c6 /var/lib/juju/tools/1.26-alpha1-trusty-amd64/tools.tar.gz
2015-11-23 23:48:24 INFO juju.cmd supercommand.go:58 running jujud [1.26-alpha1 gc]
2015-11-23 23:48:24 DEBUG juju.agent agent.go:525 read agent config, format "1.18"
2015-11-23 23:48:24 INFO juju.network network.go:242 setting prefer-ipv6 to false
2015-11-23 23:48:24 ERROR cmd supercommand.go:444 no registered provider for "lxd"
2015-11-23 23:48:25 ERROR cmd supercommand.go:448 failed to bootstrap environment: subprocess encountered error code 1

$ juju status
-- just hangs

So bootstrap failed, but the provider failed to clean up after itself.

[Eric Snow (ericsnowcurrently)]

I'm not sure I see how this is different from other providers. I don't see where other providers clean up after themselves (e.g. destroy the bootstrap instance) when there is a failure. Perhaps the difference is that StateServerInstances() returns something post-failure for the LXD provider whereas for some other providers it does not.

[Cheryl Jennings (cherylj)]

A lot has changed in the lxd provider since this bug was reported. Please re-open if you are still having problems.