juju nuke

Tim Penhey tim.penhey at canonical.com
Tue Jan 7 20:51:21 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/01/14 09:49, Casey Marshall wrote:
> When I'm debugging a charm, I'll often deploy, debug, destroy &
> redeploy that charm until I get it right. In my OpenStack
> environment, each time I deploy a service, by default it provisions
> a new machine for the new unit. However, when I destroy the
> service, the existing machines are left running idle. This exceeds
> my modest OpenStack quota pretty quick, and then I have to go pull
> the juju status, search and destroy the idle machines. (If there's
> a better way, I must be doing it wrong.)
> 
> To automate some of this, I wrote a quick and dangerous little
> juju plugin I'm provisionally calling 'juju nuke'. It will destroy
> one or more services and then go after all the machines running
> units of that service. This might be a *really bad* assumption for
> some scenarios like units co-located on the same machine, nested
> LXC deployments, etc. Don't use 'juju nuke' on a production
> environment -- this is for development environments only!
> 
> Sharing in case anyone finds it useful for developing charms:
> 
> https://gist.github.com/cmars/8306216

Thanks Casey.

Just to keep people in the loop though, we do want to change the
default behaviour of juju in this situation so it no longer keeps the
machine around.

Tim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLMaMQACgkQd1fvI4G7WRDNoACggbtY1e5gUL49VLpcCLJuiG/P
ogMAnic9Fzep9NsxeG4VzGrX+WRnazYo
=kAUY
-----END PGP SIGNATURE-----



More information about the Juju mailing list