-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hub Snapshots #565
Comments
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). GenerallyUse the sqlite database file (with buckets) for export/import/backup/restore seems reasonable to me. Few cons about exporting the raw database file first
However pros are winning IMO
FlowA 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 encryptionJust 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)? |
The encryption key is stored in a secret. The original (source) encryption key is needed to decrypt the identities when the snapshot is imported at the destination. The key (in the manifest) is encrypted using a password supplied by the user when the snapshot is created/exported. The password is used to encrypt the (encryption) key so that it is not stored in the clear in the tarball (at rest). The same password is supplied by the user when the snapshot is imported and used to decrypt the key which is then (re)encrypted using the (local) encryption key. |
One thing to consider is how does this work with OADP/velero and if we need/should write instructions for users. I think we would have to use some hook and then teach OADP how to back up the hub. Just some thoughts but something to consider as I think this will work for a lot of users, and honestly how I would probably use it, but I wonder how easy it would be to use with a tool like velero |
Just note, I think this feature should be used from UI as well as from automated tools or scripts (e.g. RHPDS), so we'd need provide |
Could you explain the user case from a user experience perspective? I understand, as a user, that I want to backup and restore. But it sounds like there are other use cases that we are discussing and trying to follow them. Sorry if this is somewhere else and I just have not read it |
@shawn-hurley I don't know anything about how to use OADP . Can you describe the steps for using OADP to satisfy the use cases? |
This issue is currently awaiting triage. |
OADP is an operator that installs velero, I would look into this: https://docs.openshift.com/container-platform/4.14/backup_and_restore/application_backup_and_restore/oadp-intro.html If you need more help we can reach out to the team internally |
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.
The text was updated successfully, but these errors were encountered: