Refactor plugin handlers to allow composable plugins.#70
Refactor plugin handlers to allow composable plugins.#70wrouesnel wants to merge 2 commits intodocker:mainfrom
Conversation
wrouesnel
force-pushed
the
combinable_handlers
branch
5 times, most recently
from
52c0c35 to
680f347
Compare
|
Also apparently I totally missed #68, though there are some differences in how we've structured our approach to the problem. |
dave-tucker
left a comment
dave-tucker
left a comment
There was a problem hiding this comment.
Can you add a usage example to README.md like the implementation in #68? This should make it a little easier to compare
| } | ||
|
|
||
| // AddImplementation adds the given implementation string to the manifest of the plugin handler. | ||
| // Unique implmentation names are only added once. |
There was a problem hiding this comment.
s/implmentation/implementation/g
This patch refactors the plugin handlers so they implement http.Handler, and exposes the individual initMux methods as public methods. This allows an advanced user to combine multiple drivers and plugin handlers under a common mux - enabling the likely use-case of a network driver and IPAM driver which should be launched together. This patch is mostly backwards compatible with the existing API with the exception of sdk.Handler.NewHandler() which by necessity is adapted to provide for step-wise addition of implementations.
wrouesnel
force-pushed
the
combinable_handlers
branch
from
680f347 to
e740047
Compare
|
Usage is virtually identical (we took the same approach). However I was experimenting with this last night and found on docker 1.13 it looks like multi-serving is bugged (possibly on earlier versions too) - moby/moby#30792 |
|
I was wondering what the status of this PR is... since it's quite old and it apparently also has some merge conflicts by now. Also, the comment regarding the docker issue mentioned in #70 (comment) Reason I am asking is that I am currently trying to do exactly what this PR seems to provide: The ability to compose a plugin with multiple providers (IPAM and network). Is this going anywhere? That said, is there a different/more modern way to create Docker (network) plugins or is this SDK/repo still "the way"? |
3 participants
This patch refactors the plugin handlers so they implement http.Handler, and
exposes the individual initMux methods as public methods. This allows an
advanced user to combine multiple drivers and plugin handlers under a common
mux - enabling the likely use-case of a network driver and IPAM driver which
should be launched together.
This patch is mostly backwards compatible with the existing API with the
exception of sdk.Handler.NewHandler() which by necessity is adapted to provide
for step-wise addition of implementations.
Closes #36.