lxc local provider sandboxing could be more complete

[Robert Collins]

In short, rather than installing zk and apt-cacher-ng and so forth on the developers environment, install them in the lxc node, similarly for what we do for other providers. Would need something running outside all the nodes to be able to do provisioning and teardown requests, but that could be very narrow and:
 - only listen on the libvirt bridge
 - use credentials supplied to the bootstrap process, so that if e.g. the libvirt bridge is on the LAN, things don't suddenly become insecure

This would allow a couple of useful features:
 - run more than one environment locally
 - closer to no overhead when not running juju
 - stop duplicating cache setups

And m_3 also points out:
11:52 < m_3> your fix would help box some of those issues too
with respect to bug 1006553

11:18 < lifeless> so, is there any way to run juju locally without getting new network services (apt-cacher-ng + zookeeper) installed ?
11:18 < lifeless> or do I need to run a kvm instance, and run juju within that ?
11:29 -!- melmoth [~melmoth@219.141.169.114] has joined #juju
11:34 < m_3> lifeless: be careful with the latter option... you can do it, but juju's lxc uses(needs) libvirt's default 192.168.122.0/24 network
11:36 < m_3> lifeless: that works though (we run local provider juju environments _within_ ec2 instances all the time for testing)
11:37 < m_3> don't know about passing new zk/apt-cache addresses into the local provider though... never tried. I'd imagine it's pretty hard-coded to localhost though
11:42 < lifeless> so, what I'd really like is to be able to shove juju into an lxc and give it a single callback to a 127.0.0.1 only service to fire up more lxc's
11:42 < lifeless> that would let me run multiple juju environments
11:43 < lifeless> as it is, I'm looking at jorge's howto for juju with lxc and wondering why-bother
11:44 < lifeless> (not why bothwe with juju, why bother with that setup; its very constrained and inflexible, and has overhead (via zk and apt-cacher-ng whether I'm using it or not)
11:46 < m_3> lifeless: like juju local provider with a bootstrapped bootstrap node that houses zk
11:46 < lifeless> right
11:46 < m_3> lifeless: kvm on a non-default libvirt network would do that right now
11:48 < m_3> lifeless: but yeah, I like your idea better... a safer sandbox for lxc. that wouldn't add extra deps to the base machine. maybe file a bug?
11:48 < m_3> lifeless: it's closer to how we use the bootstrap node in other providers (ec2) too

[Mark Mims (mark-mims)]

might be worth the extra resources to put zk, apt-cache in a dedicated bootstrap node... even if the juju provisioning agent needs to still live on the base machine to handle the lxc spinups.

[Kapil Thangavelu (hazmat)]

The local provider for was originally implemented this way by clint... ie
containers as machines with unit and machine agents living inside of them,
instead of unit containers in the host machine (machine 0). at this point
the differences between the two have no real justification. there is no
provisioning agent in a local provider case currently.

the actual reasons your giving need a little more explanation. juju is
always going to need the zk/db server to operate. the apt-cacher-ng
overhead also seems neglible for the benefit given to local envs, there is
only one cache and many users of it. multiple local envs on a single
machine are already possible (the zk port randomizes).

the overall arching goal seems to be a deployment desire of "11:42 <
lifeless> so, what I'd really like is to be able to shove juju into an lxc
and give it a single callback to a 127.0.0.1 only service to fire up more
lxc's" which could use a use case.

On Sun, Jun 17, 2012 at 8:06 PM, Mark Mims <email address hidden>wrote:

> might be worth the extra resources to put zk, apt-cache in a dedicated
> bootstrap node... even if the juju provisioning agent needs to still
> live on the base machine to handle the lxc spinups.
>
> --
> You received this bug notification because you are subscribed to juju.
> https://bugs.launchpad.net/bugs/1014435
>
> Title:
> lxc local provider sandboxing could be more complete
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1014435/+subscriptions
>

[Clint Byrum (clint-fewbar)]

It would actually be pretty simple to move the local provider ZK and cache into its own container.