Summary
The Persistence Plugin Architecture is intended to address decoupling persistence implementations from the Core Data code base. Today (Delhi release), persistence implementations are part of the EdgeX Golang Services repo. As a result, adding new persistence implementation or updating an existing implementation requires a full test of the platform. 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 architecture depends on Go Plugins.
User Stories
- As a persistence implementation provider (a provider), I want a mechanism so that I can add a new persistence implementation to the EdgeX platform.
- As a provider, I want a mechanism for sustaining a persistence implementation so that I do not rely on EdgeX platform releases.
- As a provider, I want a mechanism for configuring my implementation without knowing the rest of the EdgeX platform configuration.
- As a provider, I want the EdgeX platform build scripts to consolidate my build-time and run-time requirements so that I can maintain my implementation independently of the EdgeX platform.
- As a provider, I want an API contact so that I know what to implement.
- As a provider, I want an API contract so that I can unit test.
- As a provider, I want EdgeX platform testing to be able to certify implementation so that EdgeX platform users will the confidence to use my implementation.
- As an EdgeX platform maintainer (a maintainer), I want a default persistence implementation so that I can maintain CI/CT.
- As a maintainer, I want providers to create reasonable defaults so that I can add them into CI/CT.
- As an EdgeX platform user (a user), I want to select one or more persistence implementations for use by the various Core Data services.
- As a user, I want the option to run the platform along with the selected persistence implementation(s) directly on the OS.
- As a user, I want the option to run the platform along with the selected persistence implementation(s) in a containerized deployment.
Design
The design has two major roles: the provider and the platform.
Provider Responsibility
The provider makes their plugin,
Platform Responsibility
Acceptance Criteria
MVP
v.Next
- Provider certification
- Provider included in platform CI/CT
Other Considerations
- Could we use Go Modules instead?
Reference Patterns
The basis of the requirements came out of looking at how others have solved this challenge.
Azure IoT Edge
Azure IoT Edge is organized around independently configured modules (aka containers) that are grouped to form a solution. Each module is described independently and then combined into a solution with a deployment manifest. For example, the RedisEdge module is described using the following module.json.
{
"$schema-version": "0.0.1",
"description": "RedisEdge",
"image": {
"repository": "$CONTAINER_REGISTRY_ADDRESS/redis-edge",
"tag": {
"version": "1.0.0",
"platforms": {
"amd64": "./Dockerfile.amd64",
"arm32v7": "./Dockerfile.arm32v7",
"arm64v8": "./Dockerfile.arm64v8"
}
},
"buildOptions": []
},
"language": "javascript"
}
To build a solution with this module, a deployment manifest is constructed using scripts that parse a deployment template which enumerates the modules along with their configuration. Note the use environment variables; these are populated from a .env file that is not part of the source repository.
{
"modulesContent": {
"$edgeAgent": {
"properties.desired": {
"schemaVersion": "1.0",
"runtime": {
"type": "docker",
"settings": {
"minDockerVersion": "v1.25",
"loggingOptions": "",
"registryCredentials": {
"myiotregistery": {
"username": "$CONTAINER_REGISTRY_USERNAME",
"password": "$CONTAINER_REGISTRY_PASSWORD",
"address": "$CONTAINER_REGISTRY_ADDRESS"
}
}
}
},
"systemModules": {
"edgeAgent": {
"type": "docker",
"settings": {
"image": "mcr.microsoft.com/azureiotedge-agent:1.0",
"createOptions": ""
}
},
"edgeHub": {
"type": "docker",
"status": "running",
"restartPolicy": "always",
"settings": {
"image": "mcr.microsoft.com/azureiotedge-hub:1.0",
"createOptions": "{\"HostConfig\":{\"PortBindings\":{\"5671/tcp\":[{\"HostPort\":\"5671\"}], \"8883/tcp\":[{\"HostPort\":\"8883\"}],\"443/tcp\":[{\"HostPort\":\"443\"}]}}}"
}
}
},
"modules": {
"RedisEdge": {
"version": "1.0",
"type": "docker",
"status": "running",
"restartPolicy": "always",
"settings": {
"image": "${MODULES.RedisEdge.amd64}",
"createOptions": "{\"HostConfig\": { \"PortBindings\": { \"6379/tcp\": [ { \"HostPort\": \"6379\" } ] } } }"
}
}
}
}
},
"$edgeHub": {
"properties.desired": {
"schemaVersion": "1.0",
"routes": {},
"storeAndForwardConfiguration": {
"timeToLiveSecs": 7200
}
}
}
}
}
Which results in the following deployment manifest
{
"modulesContent": {
"$edgeAgent": {
"properties.desired": {
"schemaVersion": "1.0",
"runtime": {
"type": "docker",
"settings": {
"minDockerVersion": "v1.25",
"loggingOptions": ""
}
},
"systemModules": {
"edgeAgent": {
"type": "docker",
"settings": {
"image": "mcr.microsoft.com/azureiotedge-agent:1.0",
"createOptions": ""
}
},
"edgeHub": {
"type": "docker",
"status": "running",
"restartPolicy": "always",
"settings": {
"image": "mcr.microsoft.com/azureiotedge-hub:1.0",
"createOptions": "{\"HostConfig\":{\"PortBindings\":{\"5671/tcp\":[{\"HostPort\":\"5671\"}], \"8883/tcp\":[{\"HostPort\":\"8883\"}],\"443/tcp\":[{\"HostPort\":\"443\"}]}}}"
}
}
},
"modules": {
"RedisEdge": {
"version": "1.0",
"type": "docker",
"status": "running",
"restartPolicy": "always",
"settings": {
"image": "andresandboxregistry.azurecr.io/redis-edge:1.0.0-amd64",
"createOptions": "{\"HostConfig\": { \"PortBindings\": { \"6379/tcp\": [ { \"HostPort\": \"6379\" } ] } } }"
}
}
}
}
},
"$edgeHub": {
"properties.desired": {
"schemaVersion": "1.0",
"routes": {},
"storeAndForwardConfiguration": {
"timeToLiveSecs": 7200
}
}
}
}
}