What is the essential difference between lmctfy and LXC?

[zhang...@live.com]

    I have read [1], but I still can't quite understand the true motivation to develop such a new thing in the presence of LXC. Who can tell me more about this issue? Is there anything lmctfy can do but LXC cannot? If any, how can this difference benefit us? 

[1]http://stackoverflow.com/questions/19196495/what-is-the-difference-between-lmctfy-and-lxc

[Tim Hockin]

I thought Rohit's answer at [1] was very good, so I'll cut-n-paste and
expand a bit.


> Resource management API: LXC API is built for namespace support and exports cgroup
> support almost transparently. Linux cgroup API is unstable and hard to deal with. With
> lmctfy, we tried to provide an intent-based resource configuration without users having to
> understand the details of cgroups.

There are 2 dimensions to containment - resource isolation and
namespacing. LXC focuses on namespacing, we focused on resource
isolation. LXC's cgroup interface exposes (IMO) too much detail about
the kernel's implementation, which is subject to change between kernel
versions. We took a different approach and made it just a bit more
abstract, so users don't have to understand cgroups so much.

> Priority - Overcommitment and sharing: lmctfy is built to provide support for resource
> sharing and for overcommitting machines with batch workloads that can run when the
> machine is relatively idle. All applications specify a priority and latency requirements. lmctfy
> manages all cgroup details to honor the priority and latency requirements for each task.

We use our machines for a lot of different work at the same time, so
we focused on better Quality of Service guarantees than LXC.

> Programmatic interface: lmctfy is the lowest block of app management for Google's cloud.
> It's built to work with other tools and programs. We feel it's much better specified and
> stable for building more complicated toolchains above it.

LMCTFY is designed from day 1 to be concurrent and automatable. We
did not design for slow humans, but fast automation systems, which
means we made different trade-offs than LXC.

> We have lmctfy managing all of Google's resource isolation needs since 2007.

This is maybe the most important piece - we had our own code long
before LXC was really viable. It's highly tailored to what we need.
We thought it was worthwhile to release it. Is it better than LXC?
Let's call it different. We had different priorities, so we have a
different result.

It's our hope that people will find it useful, or at least
informational. It was not our intention to try to disrupt the LXC
ecosystem and "win" whatever that might mean :)

Cheers,

Tim

> --
> You received this message because you are subscribed to the Google Groups
> "lmctfy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lmctfy+un...@googlegroups.com.
> To post to this group, send email to lmc...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lmctfy/e77a70cb-bfbf-45e5-8e11-ce4c3edeeca8%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.