-
Notifications
You must be signed in to change notification settings - Fork 2k
Proposal: Driver Plugins #1626
Comments
To play devil's advocate for a moment, would a full fledged API (and spec) be better than distributing binaries and relying on people to get the |
Could you elaborate a bit more on how you envision this working? |
Something I thought of about driver plugins today: I think that we (the Docker Machine team) should maintain some kind of "template" / "boilerplate" repo for developing a driver plugin. It would include a |
My gut reaction to this was "why not use unix domain sockets?" but I think I do like stdin/stdout as one of the simplest possible implementations. The key is going to be making sure we handle garbage input gracefully.
Hmmm... While I agree with the sentiment, this is going to make it significantly more difficult for new users of Machine to get started than it is now. I'm not sure it'd be that difficult to implement some kind of But, I haven't thought deeply about it yet - there may be some significant roadblocks that I haven't considered ;) Also - I'm assuming this design means driver plugins can be written in any language, or is there a reason we should restrict support to drivers written in Go? |
The issue here is mainly Windows. I like Docker's "auto-detect if there's a socket in a certain directory" model, but I don't think UNIX sockets work on Windows, and using TCP sockets introduces all kinds of fun new complications ("How do I get an open port and communicate what that is" etc.).
I have a feeling this will be trickier than it looks, for a variety of reasons. It's a lot of moving parts and we want to get the local experience relatively solid before introducing distribution to the model. Distribution will be much easier to add in than to change or take out, IMO.
Depending on the model we end up going with, maybe. If we support a pure STDIN/STDOUT model, it seems theoretically feasible. However, all of the wrappers and UX niceness around development, will be Go-oriented (e.g. "Just fulfill this interface and the |
Right... Pesky old Windows 😉
Communicating open ports isn't so hard - either the parent process can open the port before execing the child process, and then communicate that as a command line flag, or the child process can report its port on stdout. However, I do agree that stdout/stdin is the simplest. 😄
Ok, that's fair. |
perhaps @jhowardmsft and @ahmetalpbalkan can chime in for additional ideas on the Windows front? |
I would like to propose that you look into the architecture of Packer's plugins system. See for some docs see docs - plugins and docs - developing plugins. To summarise the code/architecture a bit:
The main benefit of designing it this way is that it gives a Go interface to implement agains with static type checking etc and also probably makes it much easier to handle messages and debug logging in a uniform and good way. PS. I think it is extremely beneficial to quickly get a simple distribution system up and running. Something as simple as:
as soon as there is a usable plugin system. |
So far @rickard-von-essen's idea sounds good and can support Windows too (where Unix sockets are missing). I think implementing a wire-protocol RPC would be an extra thing to worry about whereas we can implement a HTTP server that has a JSON API very easily. In such a setup, what will go wrong in the long run is versioning, as Driver interface changes, the API/RPC interface will need to keep up. To address that, we can provide a “stub/base implementation” of a Machine Driver API Server in Go and by keeping the driver interface closely tied to the Go API Server interface, and we can even ensure stuff like type safety in those (e.g. missing methods) ––and even possibly API versioning like +1 for a need of distribution system. My comment on that is, a path like Are there any proposals about how the arguments of each driver will be discovered and exposed on |
https https://golang.org/pkg/net/rpc/:// https://golang.org/pkg/net/rpc/ |
I also think stdin/stdout is simplest. |
I'd like to echo @timfallmk here, if the issue is a lack of time and resources to do code reviews and managing the volume of contributions, why not ask for volunteers to focus on this part of the project? I'd be happy to review and get PRs into good shape before handing off to the maintainers to merge, I'm sure there are other folks who would also help out. This seems like adding complexity to the project in an effort to save effort, but may end up just being as much work (or more) in the end. Right now there are a lot of activity around provider drivers, but I suspect that would tail off relatively quickly. libcloud, which is arguably the most comprehensive cloud driver library, only has 102 compute drivers by my count, which is a lot, but not unmanageable. Trying to coordinate compiled binaries and/or some other plugin system seems unwieldy and more difficult to manage, not less. From a UX perspective, one of the advantages to docker machine currently is you can just drop the binary on your box and go from there, would this mean you'd now have to always enable a plugin for the providers you are using and then compile every time? Seems confusing and cumbersome for the end user. I'd love to hear from someone using docker downstream like @ibuildthecloud at Rancher to get their perspective on it, maybe they don't care. I guess I don't see an argument that the current model is broken from an architecture standpoint, so why not just continue to refine and define the driver interface? In any case, happy to contribute to whatever system ultimately is decided on, it's not that much code or time from my perspective, but this seems like not a great solution for the stated problem. If a different system is a requirement, then I'd say the one suggestion that seems the best so far (but probably also the most work) is @rickard-von-essen's but even then, seems like a lot of complexity for not a huge amount of upside IMO. |
Just throwing a small stone into the machine, as I came across Heka |
Here is the first (of hopefully monthly) Docker Machine community hangouts: https://plus.google.com/events/cs0iir01kd9ac2df7kv1k2uslts (Aug. 20 @ 3p EDT) We will be discussing this as a main topic. |
@ehazlett thanks!! +1 |
It appears we will have more people joining than hangouts supports (awesome!!). We will use BlueJeans instead (this supports up to 100 participants). Thanks! |
@ehazlett awesome!! +1 |
As a possible starting point, we could steal terraform's RPC-based plugin model... |
@hairyhenderson +1 on starting there. FWIW, I'm waiting on this PR for Packet support in terraform, it was pretty easy to port our machine driver to that: |
For anyone interested in this, my progress on driver plugins can be seen here: nathanleclaire#3 I'd love to start getting some people tinkering with it, so if you're interested in writing a plugin, let me know ([email protected] is best) and additionally I'll start putting together a little guide. It is based on the
|
Has there been any talks about Docker/Docker Machine plugin hosting on DockerHub? Or anything like a centralized list of plugins? |
We've talked about a few things in this regard. In general, what we are doing is:
|
...with the obvious caveat that this could present a catch-22 scenario... ;) |
Indeed -- it doesn't make much sense to do it for local virtualization providers for a variety of reasons. They will likely always be binaries or similar. |
Now that #1902 has landed, should this be closed? |
\o/ |
🎉 |
Project: openstack-infra/project-config c0e25e8bc5619bc1efba26c90b50ec80cdf12a77 Standalone Docker Machine driver for OpenStack docker-machine folks have designed a driver API to be able to plugin external drivers: docker/machine#1626 There is existing code in that repo, however driver is outdated, we should take over that code, update to latest dependencies (gophercloud/gophercloud), make it work with minikube etc. Change-Id: I3fb035a39243ad135ff5513f8a8b651a5fd13970
docker-machine folks have designed a driver API to be able to plugin external drivers: docker/machine#1626 There is existing code in that repo, however driver is outdated, we should take over that code, update to latest dependencies (gophercloud/gophercloud), make it work with minikube etc. Change-Id: I3fb035a39243ad135ff5513f8a8b651a5fd13970
This proposal is to start a discussion (finally) around Machine driver plugins. We have discussed this in passing before, but due to the influx in driver PRs we have pushed this up and have this slated for 0.5.
Background
Docker Machine offers an interface for creating drivers. This allowed for relatively easy driver creation which caused great feedback and response with drivers working with varying hypervisors and cloud providers. However, at this time it is proving to be extremely difficult for us to keep up with reviewing and testing each of these drivers for inclusion in the Machine core. We really want to switch to a more pluggable model, as well as polish up a few things about the driver model which need to be changed to ensure a smooth and sustainable future.
Implementation
To re-iterate, this is meant to be the start of a discussion. I'm just putting ideas here as starting blocks.
Plugin Directory
Machine Driver plugins will be stored in a known directory (i.e.
~/.docker/machine/plugins
). For the first iteration, Machine will simply list the available files in the directory and use this list as the available plugins.Binaries
Each plugin will be a binary. This makes it easy to distribute and execute.
Communication
Plugin communication would happen via
stdin
andstdout
as a JSON stream. We will need to design the spec but something like this:This would be sent as
stdin
to the plugin. The plugin would respond with something like:Distribution
For the first iteration we would not include a distribution mechanism. We would maintain a list on the wiki of available drivers and their location, maintainer, etc.
The text was updated successfully, but these errors were encountered: