Closed wfarner closed 7 years ago
What's the SPI for this? Is this something that needs to be applied more broadly to other plugin types as well? I was thinking an 'environment' plugin along these lines -- one that encapsulates state, plugin discovery and leader / non-leader into one common plugin that is run as a singleton per installation.
What's the SPI for this?
That's what i intended to sort out in the issue discussion :-)
Is this something that needs to be applied more broadly to other plugin types as well?
You mean state for other plugins? I was planning to start small and focus on flexible primitives, but focus on wiring it only to the group plugin as that's the immediate need.
I was thinking an 'environment' plugin along these lines -- one that encapsulates state, plugin discovery and leader / non-leader into one common plugin that is run as a singleton per installation.
Those seem like distinct behaviors so my inclination was to introduce them as separate plugins.
Ok - I think it's reasonable to keep it simple and just focus on helping Group manage state.
Since the group plugin doesn't have a strict schema, I am thinking along the lines of simple POST/PUT/GET/DELETE by path (namespace) with the payload as a blob with a content-type (just to make it general). This is pretty generic and can be easily backed by a variety of existing tooling - from local disk (the default) to kv stores or full-on document databases (eg. couchdb).
(Path, value) are nice since we can define namespaces for the plugins when there are many groups with different implementations.
However I think it'd be nice for the group to store its state in one atomic document / blob. So while the state store supports (path, value), a given plugin instance in practice always CRUD with a fix key/path. So maybe something (the "state" plugin) should assign the key and the plugin only needs to hand over a blob to persist or do a get
to read.
On the Go side, I'd imagine something that does upsert / delete? Deletion can be a funny thing and should warrant discussion.
Or do you have something more narrowly defined?
Or do you have something more narrowly defined?
I have nothing defined. I tend to file issues before shaping the design, so what you see is what you get :-)
I am going to introduce a PR that has only a simple Golang API to save / load a blob of some sort. This follows from the comment earlier https://github.com/docker/infrakit/issues/244#issuecomment-254981859
So the API is even simpler than a key-value store in that it's not meant to be a general key/value store. Rather, some entity will use this to persist a blob and the key / how to retrieve are implicit in the implementations. For example - if we are storing something in a swarm as an annotation then it's up to the implementation to use a defined label rather than exposing the ability to set arbitrary labels.
Removing this from v0.1.0 as there's more work to complete this in a pluggable way (i.e. the manager Group implementation in #283 includes some state which could partially satisfy this issue).
Implemented in #282. Available since v0.2.0.
The default Group plugin currently only has in-memory state for the Groups being watched. Introduce a new plugin type that the Group plugin is configured with, which delegates state management.