esraneufeld
commented
2 years ago @GitHK and me discussed a similar idea yesterday. as restoring content requires restart of the service, we probably would see the restore function on the dashboard. user could choose the restore function under the menu of a study and then would have a list of the services it contains. once the desired service for restoration is selected, the available stored content versions would be displayed. the user could than either download the file to look at the content before deciding (not sure that is even needed), or just decide to restore that content to the latest state of the study (perhaps we first save the current state, before overwriting the content, such that the user could select it from the available backup copies in case of regret). when the study is opened, it will contain the restored previous state of that service. @GitHK already has given it a bit of thought on what would be required on the backend side.
Describe the user role As an osparc user (either internal or external), I would like to retrieve lost data quickly and easily, restoring any affected studies to their pre-crash state without the need to use up valuable developer time.
Describe the goal The goal is to automate the process of data recovery on osparc. Ideally, restoring corrupt/broken studies to their most recent pre-crash versions would be a simple matter of clicking a few buttons, perhaps choosing the most recent "snapshot" of the study before the crash. While such a snapshot system is fairly ambitious, at the very least, the process of identifying the most recent workspace.zip files for each node in a study, and re-uploading them into a clean/restored version of the study should scriptable. In theory, I don't see a need for any manual intervention in this process.
Describe the benefit Automating the process of data recovery would save time and effort for both the development team and the osparc user.
Additional context As it stands, the workflow for data restoration seems to involve considerable manual intervention, eventually resulting in lists of candidate files provided by developers to the affected user, who then must cull through these lists to identify the most recent versions. The selected files are then manually uploaded to a server with associated download links which are provided to the user in a PM. The user then must download these files locally, upload them back into osparc one-by-one, unzipping them inside each affected node. In my experience, there are often many questions, requests for UUIDs, and various other complications throughout the process.