Use go 1.8 plugins for extending core functionality#556
Use go 1.8 plugins for extending core functionality#556mlaventure merged 2 commits intocontainerd:masterfrom
Conversation
Signed-off-by: Michael Crosby <[email protected]> Add registration for more subsystems via plugins Signed-off-by: Michael Crosby <[email protected]> Move content service to separate package Signed-off-by: Michael Crosby <[email protected]>
crosbymichael
force-pushed
the
plugins
branch
2 times, most recently
from
1cd4f44 to
8f534f2
Compare
linux/Makefile
Outdated
There was a problem hiding this comment.
Is there a better place for this?
There was a problem hiding this comment.
/usr/lib(64)?/containerd/plugins? Apache httpd does /usr/lib(64)?/httpd/modules and Firefox does /usr/lib(64)?/mozilla/plugins.
runtime.go
Outdated
There was a problem hiding this comment.
Nit: context stdlib can be used because 1.6 is no longer supported
There was a problem hiding this comment.
we can do an update in another pr changing all of the places that contexts are used
content/content.go
Outdated
There was a problem hiding this comment.
This is starting to get replicated in many places and we were avoiding exporting them in the packages. Can we either use a central pool or just have the packages create their own?
There was a problem hiding this comment.
Fine with keeping it like this for now, just wanted to highlight it so we remember to figure it out later :)
design/plugins.md
Outdated
There was a problem hiding this comment.
Also: s/but there is where/but this is where/
plugin.go
Outdated
There was a problem hiding this comment.
at the provided path into containerd
plugin.go
Outdated
There was a problem hiding this comment.
If the goal of this is to protect plugins from causing a panic on load then why propagate when not an error? If the panic was initiated without an error such as panic("something is wrong"), then it wouldn't get caught. Maybe either declare an error type which has an interface{} sub-value or set the error like fmt.Errorf('plugin panic: %v", v).
services/execution/service.go
Outdated
design/plugins.md
Outdated
There was a problem hiding this comment.
Also: s/but there is where/but this is where/
design/plugins.md
Outdated
There was a problem hiding this comment.
s/this can be use/ this can be used/
plugin.go
Outdated
There was a problem hiding this comment.
at the provided path...
crosbymichael
changed the title
Signed-off-by: Michael Crosby <[email protected]>
crosbymichael
force-pushed
the
plugins
branch
from
8f534f2 to
fceafeb
Compare
| type PluginType int | ||
|
|
||
| const ( | ||
| RuntimePlugin PluginType = iota + 1 |
There was a problem hiding this comment.
I assume that these are just the plugin types that you've stubbed out for now and not intended to be an exhaustive list?
There was a problem hiding this comment.
Ya, just a few that we currently have implemented
We, containerd, suggest user to use binary plugins or RPC-based plugins. Since go plugin has too many restrictions, I'm not sure that how many users use the go plugin to extend the core function in the production. Based on the fact that we put a lot of effort to make external plugins better, suggest to deprecate go-plugin type plugin in v2.0 and remove it in v2.1 REF: containerd#556 Signed-off-by: Wei Fu <[email protected]>
We, containerd, suggest user to use binary plugins or RPC-based plugins. Since go plugin has too many restrictions, I'm not sure that how many users use the go plugin to extend the core function in the production. Based on the fact that we put a lot of effort to make external plugins better, suggest to deprecate go-plugin type plugin in v2.0 and remove it in v2.1 REF: containerd#556 Signed-off-by: Wei Fu <[email protected]>
We, containerd, suggest user to use binary plugins or RPC-based plugins. Since go plugin has too many restrictions, I'm not sure that how many users use the go plugin to extend the core function in the production. Based on the fact that we put a lot of effort to make external plugins better, suggest to deprecate go-plugin type plugin in v2.0 and remove it in v2.1 REF: containerd#556 Signed-off-by: Wei Fu <[email protected]>
We, containerd, suggest user to use binary plugins or RPC-based plugins. Since go plugin has too many restrictions, I'm not sure that how many users use the go plugin to extend the core function in the production. Based on the fact that we put a lot of effort to make external plugins better, suggest to deprecate go-plugin type plugin in v2.0 and remove it in v2.1 REF: containerd#556 Signed-off-by: Wei Fu <[email protected]>
5 participants
This adds support for dynamically loading
*.sofor containerd to extend functionality in many areas. Runtime and new grpcs services to start with.It also adds a way to have type safe configuration sections in the containerd config for plugins.
Signed-off-by: Michael Crosby [email protected]