chungers
commented
7 years ago IMHO it's interesting but a few practical concerns:
- Only works on linux/ darwin
- A plugin is opened once and cannot be closed. this means restarting the entire process -- a small bug fix in an infrequently used flavor plugin would now means interrupting the operations of everything else
- It's not clear how versioning of symbols is (or how) supported. you can have a type 'Foo' that's defined in both packages but how they are matched (if one has missing struct field vs the other) and handled is not clear. Do we need to add code to handle panics everywhere? That needs more investigation.
- An extension of point above, since vendor-defined custom types would never be known to us in advance, the most we can do is represent them as json.RawMessage anyway, but now we may have more coupling in terms of typed function params like instance.Spec
A few other philosophical concerns:
- Language specific. One of the goals of using JSON-RPC in the first place was to allow other language implementations
- Isolation -- really don't want a badly written flavor plugin crash the entire process when there are multiple groups and resource types that may not even depend on it.
- Doesn't solve the problem of binary distribution and process management other than reducing the number of processes. Docker engine solves these problems and I would argue that making the plugins Docker containers or Engine Plugins (in 1.13) should take higher priority than this. This means prioritizing the implementation of discovery of infrakit plugins as Docker containers or engine plugins and on-demand pulling / starting of containers / plugins based on what's referenced in the JSON configs.
wfarner
Go 1.8 adds support for plugins, which i propose we support as a discovery mechanism for InfraKit plugins. Same-process plugins will simplify environments where the allowed/supported plugins are static and managing additional daemons causes operational overhead.
Similar to the existing support for layering Plugin interfaces with HTTP-based communication, we should provide a way to expose an implementation of our go SPIs as a go plugin.