forked from eclipse-edc/MinimumViableDataspace
-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Description
Description
As of today, two deployments are provided within the MVD:
- an Azure deployment relying on Azure managed services (such as Azure Key vault). This related to refactor: update pipelines eclipse-edc/MinimumViableDataspace#139.
- a local deployment relying on docker-compose with no dependency on any cloud managed service. This related to build(deps): bump edc from 0.1.2 to 0.1.3 eclipse-edc/MinimumViableDataspace#157.
However in most cases, participant applications are running in a cluster. Kubernetes is a well-established standard in terms of container orchestration. Thus it makes sense to also propose a MVD deployment for Kubernetes.
Acceptance Criteria
- The MVD can be deployed and run on a Kubernetes cluster based on step-by-step instructions
- A data transfer can be performed between the participants, especially the possiblity for a consumer to actively query data from a data provider exposing a REST API through its Data Plane (more details can be found here). This corresponds to the typical data-exchange use-case in Catena-X/Eona-X.
- No additional vendor specific components are required. Open-source counterparts of the well-known cloud managed services are acceptable tough (e.g. Azurite)
- Keys are stored on the local file system, or in embedded secret store provided out of the box by Kubernetes
- If keys are stored in the filesystem, then documentation should contain a security warning that keys will not be securely stored, and therefore only temporary keys for development purposes shall be used
- Integration test in CI to validate the Kubernetes deployment of the MVD (note:
Minikubeis a good candidate here) and the data transfer between the participants
Out of scope
- Local file transfer for cloud deployments
Metadata
Metadata
Assignees
Labels
No labels