LXC Directions

Thomas Hervé thomas.herve at canonical.com
Mon Jul 18 18:18:09 UTC 2011


Le 18/07/2011 19:03, Clint Byrum a écrit :

Thanks a lot for the detailed email Clint.

> ::: Two proposals :::
> 
> We have, I think, two opportunities here and now, to provide some of
> these benefits.
> 
> * LXC as a Provider - This is the way my branch works. Containers are
>   at the same level as instances on EC2.
> 
> * LXC as Unit Isolation - This would be realized by the machine agent,
>   which would create a container and spawn the unit agent inside it.

I don't know/remember enough of Ensemble internals to really understand
the difference. Doesn't the first one give you the second for free? Or
does that mean you can only have one container per machine because of
networking?

> :: LXC as a Provider
> 
> Pro's:
> 
> * Experimental branch already implemented: lp:~clint-fewbar/ensemble/lxc-container
> * Known to work and solve the LXC Local Repeatability
> * Adds support for LXC which can be used later for other needs.
> * Isolated from the rest of Ensemble, as it mostly adds a single provider on the
>   same level as EC2.
> 
> Con's:
> 
> * Does not provide unit isolation 
> * Does not provide machine re-usability
> 
> :: LXC as Unit Isolation
> 
> Pro's:
> 
> * Provides unit isolation
> * Provides machine re-usability
> * Enhances EC2 experience
> * Can take advantage of some of the LXC control work from lxc provider approach.
> 
> Con's:
> 
> * No implementation
> * Network complexity is very high 
> * Does not directly solve local dev story.

To me, the real benefit of the first is for developing formulas. That's
what we need *now*. Machine re-usability is nice, but being able to save
some cents when deploying is not a strong selling point. Having strong
isolation is interesting, but can be done after, IMHO.

-- 
Thomas




More information about the Ensemble mailing list