go-plugins-helpers icon indicating copy to clipboard operation
go-plugins-helpers copied to clipboard

Published 20 hours ago • verified publisher icon docker

Refactor plugin handlers to allow composable plugins.

Open wrouesnel opened this issue 8 years ago • 3 comments

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.

wrouesnel avatar Jan 13 '17 05:01 wrouesnel

Also apparently I totally missed #68, though there are some differences in how we've structured our approach to the problem.

wrouesnel avatar Jan 13 '17 06:01 wrouesnel

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) - https://github.com/docker/docker/issues/30792

wrouesnel avatar Feb 07 '17 21:02 wrouesnel

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 https://github.com/docker/go-plugins-helpers/pull/70#issuecomment-278142798

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

rschmied avatar Jul 09 '24 14:07 rschmied