Skip to content
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

Enhance overall VFolder removal experience #2376

Open
4 of 15 tasks
kyujin-cho opened this issue Jul 4, 2024 · 2 comments
Open
4 of 15 tasks

Enhance overall VFolder removal experience #2376

kyujin-cho opened this issue Jul 4, 2024 · 2 comments
Milestone

Comments

@kyujin-cho
Copy link
Member

kyujin-cho commented Jul 4, 2024

Motivation

File operations take a long time and are very fragile.
Backend.AI should assume that vfolder deletion process can fail at any time.

Currently, there are two design issues:

  • Purging a user account depends on the deletion of their owned vfolders.
    • If vfolder deletion takes a long time or fails, it may prevent the admins from purging user accounts.
  • VFolders in the trash bin should always be restorable.
    • We should hide the vfolders "being deleted" in the filesystem from the users.
    • However, we should show them to the admin so that they can inspect and delete interrupted ones manually.

This is a follow-up to:

and the completion of:

Proposed implementation details

Decoupling user account purging and vfolder deletion

Moving to trash bin

  • When a user moves a vfolder to trash bin by calling DELETE /vfolders or DELETE /vfolders/{name} API
    • The vfolder state transits to DELETE_PENDING.
    • The filesystem remains unaffected.

Deleting forever

  • Upon one of the following events:
    • When the user deletes the vfolder from the trash bin via DELETE /vfolders/delete-from-trash-bin API
      • Including when the admin triggers manual deletion of a vfolder in the trash bin via the control panel
        • Update the control-panel UI to show the vfolders in the DELETE_{ONGOING|ERROR} state.
        • Update the control-panel UI to show the orphan vfolders in the DELETE_PENDING state with their owner users/projects gone.
    • When the user "flushes" the entire trash bin via POST /vfolders/flush,
    • When the user or an external service triggers immediate deletion of a vfolder via ... API,
    • When the system triggers periodic cleanup of old vfolders in the trash bin,
    • Or, when the system triggers periodic cleanup of interrupted vfolder deletions,
  • Do:

History cleanup

  • Never delete the vfolders records during the deletion process. Only delete vfolders in the DELETE_COMPLETE state after the data rentention period.
  • User removes database record of VFolder in DELETE_COMPLETED status by calling DELETE /vfolders/purge API
    • Replace this with backend.ai mgr clear-history.
@kyujin-cho kyujin-cho added the type:feature Add new features label Jul 4, 2024
@kyujin-cho kyujin-cho added this to the 24.03 milestone Jul 4, 2024
@fregataa
Copy link
Member

fregataa commented Jul 6, 2024

We made a glossary related to VFolder deletion.

  • move to trash: transit VFolder status to DELETE_PENDING and actual contents remains
  • delete forever: delete the actual contents of the VFolder
  • restore: transit VFolder status from DELETE_PENDING to READY

Does this issue suggest to replace delete forever with flush or add support for flush?

@achimnol
Copy link
Member

achimnol commented Jul 8, 2024

Since the filesystem-level deletion process can take a long time, or gets failed and retried afterwards, we should show a small notice to the users like: "The deletion process and restoring the available storage space may take up to 12 hours."

achimnol added a commit that referenced this issue Jul 9, 2024
…2404)

refs #2376

Remove the foreign/check constraints preventing decoupling of user/vfolder deletions.

**Checklist:** (if applicable)

- [x] Milestone metadata specifying the target backport version
- [x] Mention to the original issue
lablup-octodog pushed a commit that referenced this issue Jul 9, 2024
…2404)

refs #2376

Remove the foreign/check constraints preventing decoupling of user/vfolder deletions.

**Checklist:** (if applicable)

- [x] Milestone metadata specifying the target backport version
- [x] Mention to the original issue

Backported-from: main (24.09)
Backported-to: 24.03
Backport-of: 2404
lablup-octodog added a commit that referenced this issue Jul 13, 2024
…2404) (#2406)

refs #2376

Co-authored-by: achimnol <[email protected]>
Remove the foreign/check constraints preventing decoupling of user/vfolder deletions.
Backported-from: main (24.09)
Backported-to: 24.03
Backport-of: 2404
jopemachine pushed a commit that referenced this issue Jul 14, 2024
…2404)

refs #2376

Remove the foreign/check constraints preventing decoupling of user/vfolder deletions.

**Checklist:** (if applicable)

- [x] Milestone metadata specifying the target backport version
- [x] Mention to the original issue
@achimnol achimnol removed the type:feature Add new features label Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants