LGTM! 👍

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)

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

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.

@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

@docker/maintainers please, make sure you check this PR, because it's happening 😁

@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.

@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.

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.

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

@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).

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

@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 😄

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

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

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.

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.

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.

Btw, libnetwork depends on .dockerinit inside container.

LGTM

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

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?

@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.

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?

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

@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?

@kimh There should be nothing stopping it.