Promote containers to being plugins

[lukemarsden]

@shykes mentioned that he would prefer docker plugin load to be implemented as two steps:

• starting a regular container
• promoting it to being a plugin somehow.

See comments on https://docs.google.com/a/clusterhq.com/document/d/1wg5_O8RzwN9POqqLK1zq1tzkwAm630YSpy_Re1QhcnM/edit#heading=h.9jiakz3mhr72

[lukemarsden]

@progrium mentioned that you might as well just do docker run --plugin in this case. It's not clear what the value to making it a two-step process is...

[shykes]

I agree with having docker run --plugin. But I think it should be syntactic sugar for the 2 steps - mostly to avoid turning run into even more of an untangled mess than it already is.

[progrium]

But nobody will do those two steps. They will always just do --plugin.
Trust me. That makes the two steps kind of pointless. I know run is a
tangled mess. But this is not the way to solve that problem. I've got
unrelated strategies for that if you're interested.

On Tue, Apr 28, 2015 at 12:17 PM, Solomon Hykes notifications@github.com
wrote:

I agree with having docker run --plugin. But I think it should be
syntactic sugar for the 2 steps - mostly to avoid turning run into even
more of an untangled mess than it already is.

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

Jeff Lindsay
http://progrium.com

[shykes]

What if I want to disable a plugin, or replace it with a newer version?

Almost everything that is harcoded in "docker run", we now regret not
having available as a dynamic command. For example: mounting volumes,
toggling privileged mode, exposing ports... The list goes on.

On Tue, Apr 28, 2015 at 10:23 AM, Jeff Lindsay notifications@github.com
wrote:

But nobody will do those two steps. They will always just do --plugin.
Trust me. That makes the two steps kind of pointless. I know run is a
tangled mess. But this is not the way to solve that problem. I've got
unrelated strategies for that if you're interested.

On Tue, Apr 28, 2015 at 12:17 PM, Solomon Hykes notifications@github.com
wrote:

I agree with having docker run --plugin. But I think it should be
syntactic sugar for the 2 steps - mostly to avoid turning run into even
more of an untangled mess than it already is.

—
Reply to this email directly or view it on GitHub
<
#13 (comment)

.

Jeff Lindsay
http://progrium.com

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

[progrium]

I see, I see. That suggests a fundamentally different model though. In that world, it makes sense.

Currently though, disabling or replacing would be done the same way as with any other containerized service. You stop or remove it, run the new version. No reason to add extra semantics of disable/enable. Unless they fall out for free from an internal model where all these properties can be changed at runtime. But I'm saying it's not necessary from a use perspective, right?