Unit assignment to "unused" machines

Clint Byrum clint at ubuntu.com
Mon Dec 26 16:28:35 UTC 2011

Excerpts from Gustavo Niemeyer's message of Mon Dec 26 04:54:23 -0800 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).

I have to agree that the ideal scenario has each unit inside an LXC
container so that it is *very* easy to wipe away from the machine. It
should also make the storage implementation easier once we come to
that bridge, because we'll be able to mount storage at a predictable
location as the "root" of the container and unmount it knowing there
are no processes holding it open (rather than having to do some kind of
secondary mount and then direct services to use it).

I think the discussion on LXC everywhere has stalled on the networking
complexity problem. I wonder if we shouldn't experiment with using LXC
without networking being namespaced. There is a way to use it where the
container shares the entire network namespace with the host, so ifconfig
shows the same interfaces/ips and netstat shows the same ports in use.

One need only leave off the networking parameters in lxc.conf and you
get a container that is otherwise perfectly capable of being cleaned up.
I do think we'd need to still consider the congtainer's root as having
root on the host, *but* thats ok, we're just looking to LXC for isolation
of processes and files while we figure out networking.

More information about the Juju mailing list