Unit assignment to "unused" machines

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Mon Dec 26 12:54:23 UTC 2011


Hi Adam,

> 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...

This is an interesting point of view, and I'll ponder it about it for sure.

The overall problem I perceive in this scenario is that most users
don't care about the scenario you're talking about, and as a
consequence they will do a poor job on that specific area because
that's alright. Then, it becomes a problem of juju itself, because we
can't encourage or allow a given workflow to be used if it's error
prone and generally broken. If functionality of remove + deploy is
generally broken, the whole system becomes a bit pointless, no matter
who we blame for that.

For these reasons, I'd prefer to invest our time in a way that
relieves everybody from thinking about the problem (LXC) rather than
requiring everybody to remind of it all the time (destroy hook).

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.



More information about the Juju mailing list