aufi
commented
7 months ago Hey Jeff, sounds good, I'm adding few quick notes on this topic from slightly different point of view (to ideally get the best solution in the end).
Generally
Use the sqlite database file (with buckets) for export/import/backup/restore seems reasonable to me.
Few cons about exporting the raw database file first
- partial imports are not possible (e.g. python script does GETs on all resources from import dump before actual POST calls, so if there is no collision in IDs, data can be imported even to non-empty Hub)
- it will be harder to change exported data manually before import
However pros are winning IMO
- database versioning&migrations => allows import (most of) older export archives (Hub API doesn't have anything like that)
- work with all-in-one archive, not needed to update this feature with each API resources change
- ...
Flow
A logic managing Snapshots might not be that far from some kind of Tenancy (separation of Konveyor data to Projects). Not exactly with the Flow described above, but if such feature would be reasonable to PM/Ramon, implement a switching of data files (sqlite&buckets) instead of have multiple snapshots and deploy those to the working path might be worth discussion (at least to clarify this does or does not make sense).
Identities encryption
Just to be sure I understand correctly. An encryption key is not part of database, but comes fom Hub env (so will not be exported from the Konveyor instance and thats reason an export key is needed to re-encrypt idetities without exporting original key)?
jortel
shawn-hurley
konveyor-ci-bot[bot]
Use Cases
Note: all use cases can performed using API or UI.
As a user, I want to backup the inventory.
As a user, I want to restore a specific snapshot of the inventory.
As a user, I can list, create and delete snapshots.
As a user, I want to demo using a (choice of) snapshots of the inventory.
Overview
A Hub snapshot contains the DB and bucket/file data. They can be used to prime an instance for demos, backup/restore and reverting to a snapshot in time.
Snapshot Anatomy (tarball):
Snapshots stored on the /snapshot PV.
Workflows:
List
route: GET /snapshots returns: A list of created or uploaded snapshots. (Listing of name: found in manifests).
Export
route: POST /snapshots/export body: A password used to encrypt the encryption key. returns: streamed snapshot (tarball).
Create
route: POST /snapshots/:name actions:
Import
route: POST /snapshots/import/:name body: multi-part file upload of a tarball and the password used to encrypt the encryption key. action:
Deploy
route: POST /snapshot/deploy/:name action: Create a symlink /snapshot/deploy => the snapshot (directory) to be deployed.
Deploy Flow in Hub main.