Code review comment for lp:~axwalk/juju-core/juju-failed-bootstrap-destroy-jenv

On 2014/02/03 07:20:58, wallyworld wrote:
> I'm not sure about this. I think we're getting to the point where the
mental
> model is getting too complicated and exposes too much of Juju's
internals. Why
> not just go ahead and remove the jenv file automatically under the
circumstances
> described ie no previous jenv file, bootstrap fails, destroy files, so
remove
> jenv.

If we dispose of the .jenv file without attempting to destroy the
environment,
then the user cannot automatically release any partially created
environment.

> What's the use case for stand alone use of the --config-only option?
If the
> cloud artefacts are already gone, we could just inform the user that
their cloud
> env has disappeared and did they want to clean up the remaining local
config,
> and if they say yes, just do it.

The reason it exists is to clean up if bootstrap fails *and* the auto
destroy-environment fails. It would be nice if we could automatically
determine that this can be done and just do it, but I'm not convinced
it's practical.

How do you tell that the cloud artefacts are gone? By going to the
provider. What if you can't get to the provider because your config is
wrong? How can Juju tell the difference between a temporarily wrong
config and a permanently wrong one?

https://codereview.appspot.com/59560043/