On 2014/02/03 08:03:18, wallyworld wrote:
> On 2014/02/03 07:34:06, axw wrote:
> > 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?

> I think there's 2 main use cases?
> 1. Bootstrap of new env fails
> In this case, we know the that jenv file did not previously exist so
if
> auto-destroy fails, we can (probably after asking) offer to the user
that any
> remaining juju configuration files be cleaned up and so leave their
system as it
> was prior to the initial bootstrap.
> 2. Someone deletes cloud artefacts outside of juju
> So now the user may see that juju commands fail and they want to clean
up. So
> they juju destroy-env. It fails cause stuff has already been deleted.
So like in
> the first case above, we can just prompt them that their config will
be deleted.
> Here the wording of the prompt will be slightly different but the end
result is
> the same.

> I guess there's a danger that if there's some transient failure
reaching the
> cloud we could remove the jenv and leave the user with cloud resources
still
> active. We could incorporate this into the above prompts eg "Juju
cannot contact
> the cloud to delete any running instances, this may be a temporary
failure, did
> you want to try again or just nuke your env config". If they elect to
clean up
> the config, we can let them know that they should ensure that nothing
is left
> running, Juju tried but failed so now it's up to them.

> I guess my main wish is that the user be guided as to what to do and
the tool
> does it at a high enough level that they don't have to try and
understand the
> internal workings of Juju, as opposed to exiting and making them run a
command
> with yet another option. And like destroy-environment -y, the user
could allow
> juju to do what it thinks needs to be done without prompting.

Fair call about it being too low-level. I'm just not keen on adding
prompting to hide the implementation details.

I'll pare this back a bit so we attempt to destroy after a failed
bootstrap, but remove all the --config-only bits from the CL. We will
probably still want to address that at a later date.

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