Unit assignment to "unused" machines

[Adam Gandelman]

I'm with Nick. The more I use Juju on bare-metal, the more I want to 
eliminate the need to provision a fresh machine from scratch.  I've come 
to depend on machine re-use to speed up my work flow both in terms of 
pre-provisioning and as well as complete reuse (deploy service A, 
destroy, deploy service B).  But, I understand the challenges here.

> 1) No stop hooks will be fired (lp:802995; lp:872264). So, an "unused"
> machine is in fact still running the original service unit. OK, we
> should fix those bugs by 12.04; and assuming we do, we can forget about
> *this* point. But:

It seems a bit unfortunate that the only teardown event hook that exists 
is 'stop'    I've found myself wishing for an additional and optional 
'destroy' hook which does what it can to make sure the destroyed service 
and traces of it are removed from the system as best it can (service 
$foo stop; dpkg -P $foo, rm -rf this, rm -rf that, etc)  The stop hook 
could, in theory, be used to do some of this cleanup but AFAIK it may 
also be called at other times during the units lifecycle to temporarily 
stop the service.  I've got some ideas brewing about very interesting 
things I could do with a 'destroy-unit' hook that would help speed up 
some of the integration testing we plan on using Juju to drive, but 
thats for another thread...


>
> 2) Even if we *do* fire the stop hooks, we don't have any guarantee that
> the stop hook has *actually* shut down the service properly... AFAICT,
> we can only guarantee that the machine is genuinely unused once we've
> implemented unit containerization -- which surely won't happen by 12.04
> -- and actually stopped the *container* itself.

IMHO as a user, there's only so much Juju itself can guarantee. There 
are some guarantees that must be made by charms + charmers themselves.  
If I (user/charmer) were given the optional tear-down hook, and the 
ability to toggle machine reuse per env. (disabled by default?), the 
blame for the failed recycling a machine rests on my shoulders, not 
Juju's.  That is user error.  I'd be happy with that responsibility, as 
it would let me experiment, break it often and come up with "really cool 
stuff" in the end.  Being too strict and trying too hard to eliminate 
*every* potential for user error really limits this, for me anyway...


Cheers,
Adam