
Lmctfy – Let Me Contain That for You - tvvocold
https://github.com/google/lmctfy
======
GauntletWizard
As a former Google SRE, I'm pretty annoyed with the number of abstractions,
indirections, and arbitrary features being pumped into docker. The core
concept of Containers is supposed to be that you write to the unix process
model, and the process model alone; Not create new systems from whole cloth in
overly abstract ways.

This doesn't work for a lot of legacy systems, but rather than port or write
new systems to do those functions, the Docker model seems to have absorbed all
the hacks without documenting any of the best practices, allowing anyone who's
going about creating new systems to wander off into the weeds of subfeatures
and hacks.

Unfortunately, the LMCTFY project seems to be dead; They're porting features
into the already bloated libcontainer, though I'm certain the borglet it is
based on stays fairly pristine. LMCTFY and the google stack are a very
different style of systems administration than is currently in vogue; but
together they create a beautiful and pristine ecosystem with very few rough
edges.

Anyway: If you want to know what you should be building with Docker, figure
out how you would build it with just what LMCTFY provides. Some of it is non-
obvious (Service discovery is a core service that exists in many forms, but
few that are analogous/replacements for what the google stack needs), but by
paring down what you work with, you ultimately create much tighter, more
reliable systems.

~~~
elcct
> I'm pretty annoyed with the number of abstractions, indirections, and
> arbitrary features being pumped into docker

You have to keep adding features in order do get funding. I call it Funding
Driven Programming (FDP)

~~~
juliangregorian
Docker core is still not as secure nor as humane as I would hope for from a
1.0 release, but they're investing all their time into compose, swarm,
machine, most of which are barely more mature than a hackathon project. The
libcontainer partnerships are great, but yeah, I think you're exactly right,
all the funding has tainted their core mission.

~~~
shykes
Hi, having started Docker I am of course biased, but I thought I'd bring some
data to this conversation.

Last 30 days on Docker Compose: 45 PRs merged from 26 people

Full time Docker employees on Compose: 1

Last 30 days on Docker Machine: 39 PRs merged from 33 people

Full time Docker employees on Machine: 1

Last 30 days on Docker Swarm: 50 PRs merged from 21 people

Full time employees on Swarm: 3

Last 30 days on Docker core: 265 PRs merged from 161 people

Full time employees on core: 8

The lmctfy authors are now core maintainers of runC (and its underlying
libcontainer) which they built together with Docker core maintainers. Together
they built something robust and operationally sound, based on their combined
experience running containers in production.

Overall, lots of great tools being developed, at different levels of maturity,
some focused on low-level operations and some focused on helping developers. I
don't understand the negativity.

Edit: the lmctfy authors, unlike the grand-parent in this thread, have been
super pragmatic about the pros and cons of the Google stack vs others. They
realize that it's a big and complex world out there, and that not every
computer system can make the same simplifying assumptions as Google. Only a
relatively unexperienced SRE would assume that you can build any system on top
of their employer's custom tools, unmodified. To take an obvious example:
nested cgrouls and performance profiles are really sweet, but last I checked,
net namespace support was not a priority because "we don't need it at Google".
Welcome to the real world, GauntletWizard.

~~~
icebraining
As a side note, is there any way to view a graph of open PRs over time? It
could be a good test of the health of a repo.

~~~
shykes
I just look at the "pulse" section on github. We also have an internal tool
which we query for more complex queries (contributor retention across
projects, things like that).

------
rwmj
Sounds at least superficially like libvirt-sandbox. Libvirt-sandbox has the
possible advantage that with a single switch you can use either a container or
a full virt (qemu) process to contain the task.

------
vacri
> _lmctfy (pronounced l-m-c-t-fi, IPA: /ɛlɛmsitifаɪ/)_

I always read this as "lamictify", having worked with patients on 'lamictal'
for a few years.

~~~
Jgrubb
I've heard it pronounced lim-cut-fee, so if I ever said the word out loud,
that's probably how I'd pronounce it too...

~~~
nickstinemates
A lot of googlers even pronounce it differently. Glad the repo finally takes a
stand!

------
kungfooman
Google knows how not to use GPL AIDS licenses, thanks!

