search

ClusterHQ / docker-plugins

A temporary fork of Docker for working on docker plugin mechanism (mainly for issue tracker, wiki)
Apache License 2.0
1 stars 2 forks source link

Promote containers to being plugins #13

Open lukemarsden opened 9 years ago

lukemarsden commented 9 years ago

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

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

lukemarsden commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 https://github.com/ClusterHQ/docker-plugins/issues/13#issuecomment-97141834 .

Jeff Lindsay http://progrium.com

shykes commented 9 years ago

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 < https://github.com/ClusterHQ/docker-plugins/issues/13#issuecomment-97141834

.

Jeff Lindsay http://progrium.com

— Reply to this email directly or view it on GitHub https://github.com/ClusterHQ/docker-plugins/issues/13#issuecomment-97143027 .

progrium commented 9 years ago

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?