Revision History
| Date | Who | What |
|---|
| 20190102 | Andre | Initial draft |
| 20190103 | Trevor | Added clarifications |
| 20190106 | Andre | v0.0.1 |
| 20190117 | Trevor | Added Discussion Notes |
** Updated Discussion Notes **
On 17-Jan-2019 we discussed the following proposal in the Core Working Group call. Full recording and meeting minutes can be found here. The current plan of action for Edinburgh is as follows:
- We will defer usage of plugins until a later development cycle, Fuji at the earliest.
- For Edinburgh, we are committed to supporting Mongo and Redis at the persistence layer for relevant services within the edgex-go repo. These implementations will be a part of the edgex-go source tree, as they were for the Delhi release.
- Andre at Redis has committed to closing any necessary gaps to support all relevant services with a tentative delivery of 15-Mar-2019
- An alternate approach to plugins was proposed by ObjectBox (see #corewg-persist channel on Slack) which would utilize Go modules to externalize 3rd party implementations. Ivan / Markus at ObjectBox agreed to provide a POC for the group demonstrating this approach. Once that is ready, we will cover it in a subsequent Core Working Group call.
- Resources at Microsoft and Intel are conferring with regard to the open issue detailing the lack of plugin support for Windows. Hoping for traction here leading to acceptance for a future Go version.
Summary
The Persistence Plugin Architecture is intended to address decoupling persistence implementations from the EdgeX Foundry code base. The core-data, core-metadata, export-client, support-logging and support-notifications services all currently rely on database persistence. Today (Delhi release), persistence implementations are part and parcel of the EdgeX Golang Services repo. As a result, adding a new persistence implementation or updating an existing implementation requires all team members to have knowledge of every supported persistence platform as well as access to an installation of each in order to fully test any changes. New capabilities must be added to every persistence implementation before they can be called complete. This is not scalable. For a future (Edinburgh) release, the goal is to move persistence implementations into their own repos so they can be maintained independently of the EdgeX code base.
...
The provider repo follows the Go standard project layout. In addition, providers are encouraged to maintain and distribute prebuilt binaries of their plugin.
| Path | Description |
|---|---|
| `pkg/NAME.so.VERSION` | The plugin lives in the pkg directory where NAME is the plugin name and VERSION follows Semantic Versioning 2.0. |
| `pkg/NAME-docker-compose-fragment.VERSION.yml` | Addition to the Docker Compose file for the persistence service (aka the DB). Optional. |
| `pkg/NAME-config.VERSION` | Persistence service configuration file. Optional. |
Note NAME and VERSION must match across plugin, compose file fragment, and configuration file.
...
In addition to overloading the Type key, two additional keys are added. The plugin, compose file fragment, and configuration file are copied to `cmd/SERVICE/plugins`.
| Key | Description |
|---|---|
| Type | The Type key currently drives a switch statement in the service initialization code. If the key is not recognized in as a known value, it is assumed to name the plugin. |
| Version | The Version key is used to complete the name for the plugin as well as the name for the other dependencies. |
| PluginSource | The PluginSource key provides the path to the plugin as well the path for the other dependencies. It can be a URL or a local file path. |
The compose file fragment is merged into the Docker Compose file for the service. If there is a configuration file it is mounted as part of the compose file.
...