28 lines
1.4 KiB
Markdown
28 lines
1.4 KiB
Markdown
# migration data model requirements
|
|
|
|
Given:
|
|
|
|
- no change in control of domains;
|
|
- two Fediversity set-ups (to be provided by ProcoliX) with a run-time environment such as ProxmoX, for an initial test using the same version;
|
|
- an operator's configuration, including:
|
|
- DNS automation hooks for the desired domain (RFC 2136, optionally authenticated by TSIG (RFC 2845) or GSS-TSIG (RFC 3645));
|
|
- a Fediversity configuration of at least a single application (to start).
|
|
|
|
Our data model must describe a migration:
|
|
|
|
- specifying [entity relations](https://mermaid.js.org/syntax/entityRelationshipDiagram.html#relationship-syntax) e.g. many-to-many;
|
|
- migrating both deployed and staged configurations;
|
|
- deploying of applications using the same versions;
|
|
- retaining relevant application state;
|
|
- handling of application-specific migration logic, such as to rewrite URLs as needed;
|
|
|
|
Tests:
|
|
|
|
1.
|
|
A Fediversity user may wish to migrate their Fediversity set-up between monolithic and distributed configurations.
|
|
In an admin screen they can get their configuration and data for transfer.
|
|
Using this they may migrate to the desired configuration.
|
|
1.
|
|
At any time a Fediversity user may wish to migrate their Fediversity set-up.
|
|
They can go to an admin screen where they can get their configuration and data for transfer.
|
|
This data can be provided to a new service provider where they will be up-and-running again, with minimal downtime.
|