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