Introduce a plugin type to manage Group state

[wfarner]

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.

[chungers]

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.

[wfarner]

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.

[chungers]

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?

[wfarner]

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 :-)

[chungers]

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 #244 (comment)

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.

[wfarner]

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).

[chungers]

Implemented in #282. Available since v0.2.0.