Remove LXC support.

[calavera]

The LXC driver was deprecated in Docker 1.8.
Following the deprecation rules, we can remove a deprecated feature
after two major releases. LXC won't be supported anymore starting on Docker 1.10.

It also removes the global daemon option --exec-driver because it doesn't make sense anymore.

Signed-off-by: David Calavera david.calavera@gmail.com

[tianon]

LGTM! 👍

[thaJeztah]

Think there's also some docs around lxc here https://github.com/docker/docker/blob/master/docs/reference/run.md#runtime-privilege-linux-capabilities-and-lxc-configuration (but we're not in docs review yet)

[cpuguy83]

runconfig/parse.go:65: flLxcOpts declared and not used

[calavera]

thanks @cpuguy83

@thaJeztah yeah, I left a few things behind. I wanted to check if it actually worked :)
There are a few things in contrib that I don't really know how to clean, apparmor, selinux and other related scripts.

[thaJeztah]

@calavera no problem, just mentioned it so that we don't skip docs review on this one. I can help checking once we're there

[calavera]

please, make sure you check this PR, because it's happening 😁

[tiborvass]

ugh i know it's silly but if we could merge this at the same time as #17701 to suffer only one cache bust :)

[calavera]

we can put both changes in the same PR to merge them at the same time, although it's unusual.

[vieux]

@calavera are we going to keep the execdrivers since there is only one now ?
I think it's a good idea if one another ever pops up.

[calavera]

@vieux that's a very good question. Maybe we can just remove that option all together. After all, windows and linux are already separated by build flags.

[calavera]

I've also removed the global daemon option --exec-driver in a separated commit. Because as @vieux mentions, it doesn't make sense to keep it anymore.

[rhatdan]

Does this mean dockerinit goes away? Can we switch to building docker as dynbinary as default?

[vdemeester]

@calavera the --exec-driver flag will go without deprecation notice though, right ? (I don't think this is a bad thing but prefer to mention/ask about it).

[cpuguy83]

Yeah, thought abut this too. Ultimately I think it should fail and not just silently ignore the fact that the user was specifying LXC.

[calavera]

@rhatdan dynbinary has been the default since 1.8.

@vdemeester yes it goes away without deprecation notice. It doesn't make sense to keep it as deprecated when it doesn't do anything.

@cpuguy83 it fails if you set the flag, because the parser doesn't recognize that option 😄

[vdemeester]

@calavera ok,seems fair. LGTM then :-)

[ewindisch]

Conceptually, LGTM! Only glanced at the change itself, but nothing shocking.

[tiborvass]

I'm not sure about removing --exec-driver even if there's just now one driver left. In fact there are two drivers left, one windows and libcontainer even if you can't really choose between them because they are for different platforms.

Still, removing --exec-driver is dependent on the runc integration, since runc integration is what will give people a way to write and choose exec drivers. But those decisions are not finalized. If today, we remove the flag only to add it back later, it doesn't make sense. I prefer to live with a nop flag then with back and forth decisions.

To complicate the matter further, I'd be interested in moving the --exec-driver flag to the run command so that i can have multiple exec drivers at the same time.

[calavera]

To complicate the matter further, I'd be interested in moving the --exec-driver flag to the run command so that i can have multiple exec drivers at the same time.

@tiborvass That's one more reason to remove this flag from the daemon. It's a completely different feature.

I'd rather not keep flags that we don't use only just in case. It will be easier to move forward with runc if we start with a clean slate and we don't try to keep the old idioms around only because we had them already.

@crosbymichael I'd really appreciate your input in this.

[tiborvass]

It will be easier to move forward with runc if we start with a clean slate and we don't try to keep the old idioms around only because we had them already.

@calavera that's why it's the runc integration PR that should remove the flag.

Anyway I won't fight it.

[LK4D4]

Btw, libnetwork depends on .dockerinit inside container.

[cpuguy83]

[jessfraz]

hahaha that could be a phase 2?

[calavera]

@LK4D4 it looks like .dockerinit still exists in a container booted with this branch, I'm not sure if this changes anything:

➜  docker git:(remove_lxc) bundles/1.10.0-dev/binary/docker run --rm -it alpine ash
/ # ls -la
total 56
drwxr-xr-x   17 root     root          4096 Nov  5 21:15 .
drwxr-xr-x   17 root     root          4096 Nov  5 21:15 ..
-rwxr-xr-x    1 root     root             0 Nov  5 21:15 .dockerenv
-rwxr-xr-x    1 root     root             0 Nov  5 21:15 .dockerinit
drwxr-xr-x    2 root     root          4096 Sep 14 19:17 bin

It looks like libnetwork only uses that file to decide whether to raise an error or not. I'm not sure if we need to do anything, but if we do, maybe it's something that we can do in some other way that doesn't block this PR:

https://github.com/docker/libnetwork/blob/9fb7ba8fa01f0ddce99713799e760223c842fb4b/drivers/bridge/setup_bridgenetfiltering.go#L36-L41

[tianon]

AFAIUI, this PR technically opens the possibility of ditching dockerinit, but IMO that discussion should be separate from this PR.

[calavera]

I agree with @tianon

[jessfraz]

LGTM

[jessfraz]

lets move ahead!

[thaJeztah]

@calavera impact/deprecation too? It's marked deprecated already, but for easier finding.. Idk

[calavera]

@thaJeztah impact/💀 maybe? 😁

[vdemeester]

impact/👻

[thaJeztah]

impact/byebye-it-was-nice-knowing-you-but-we-moved-on

[jessfraz]

impact/RIP-jess-is-glad-for-after-over-2-years-never-having-to-run-lxc-start-again
😇

On Thu, Nov 5, 2015 at 2:53 PM, Sebastiaan van Stijn <
notifications@github.com> wrote:

impact/byebye-it-was-nice-knowing-you-but-we-moved-on

—
Reply to this email directly or view it on GitHub
docker#17700 (comment).

[thaJeztah]

impact deprecate !rebuild docker#17700/lxc

[shykes]

LGTM

[michaelneale]

[jhowardmsft]

Ah please leave --exec-driver for the moment. There will soon be two Windows drivers while I'm developing the libcontainer Windows one

[xnox]

How is OCI exec driver going to be added?

Note that native driver / libcontainer != OCI. There are three OCI complaint executors already: clr, runv, runc. With only one of them based on libcontainer bits.

This kills clr exec-driver that uses VMs on Linux, which Highland team was about to be piloting to use. And which was requested to be merged to master...

Given that imminently we will need oci exec driver to supplement and migrate from native driver on linux at least, removing this support adds no value, and makes current and future development match harder.

Please revert?

[stevvooe]

@xnox Might be better to open a separate issue rather than commenting on a closed pull request. I would also suggest you be more specific about why this affects OCI integration.

[kimh]

I just want to be clear, but does this PR mean that I cannot run Docker on LXC from docker 1.10? Or is there a way other than using --exec-driver lxc to do this?

In other words, what should I do if I want to keep using Docker on LXC?

[thaJeztah]

@kimh correct; are there specific reasons you cannot use the "native" driver?

[kimh]

@thaJeztah

I work in CircleCI and we use LXC container to run builds. Therefore, we've used LXC exec-driver to run Docker.

are there specific reasons you cannot use the "native" driver?

Actually, I'm wondering if I can use libcontainer on LXC and made this SO question which led me to this PR.

So repeating the same question, is it technically possible to use libcontainer driver on LXC container?

[cpuguy83]

@kimh There should be nothing stopping it.