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

Revisit the unmanaged vfolder with the latest storage-proxy architecture #2313

Open
achimnol opened this issue Jun 19, 2024 · 0 comments
Open
Labels
comp:manager Related to Manager component comp:storage-proxy Related to Storage proxy component urgency:4 As soon as feasible, implementation is essential.
Milestone

Comments

@achimnol
Copy link
Member

achimnol commented Jun 19, 2024

Unmanaged vfolders allow superadmins to map a random host path to a vfolder, in case that users need to cooperate with external systems which use a specific host path or sub-path in shared network volumes, not following our quota-scope and vfolder path mangling scheme.

Note

Characteristics of unmanaged vfolders:

  • It assumes that all agents have the same host-side paths that map to unmanaged vfolders.
  • Users cannot create or delete unmanaged vfolders in Backend.AI, while they can mount them into the sessions.
  • Unmanaged vfolders are not accelerated in terms of the filesystem operations as we don't have information about its storage host but only the agent path. Depending on the agent's OS and storage configuration, GDS may work though.
    • They don't have the owner vfolder host.
  • Unmanaged vfolders cannot be cloned.
  • Only admins can create unmanaged vfolders in the control panel or CLI.
    • Backend.AI does neither perform any filesystem-level validation nor directory creation when creating them. It just adds a database record to keep track of the new unmanaged vfolder.
  • They are not part of our quota scopes and the quota management should be configured manually by customer admins.
  • When an unmanaged vfolder is deleted, it skips the trash bin and immediately disappears from Backend.AI. Though, since it is unmanaged, actual storage-level deletion should be done by customer admins.

For instance, a vfolder created with ./backend.ai vfolder create --unmanaged unfolder1 /home/joongi/unfolder1,
image

Issue: unmanaged vfolders do not work with the current backend-aware storage-proxy implementation with explicit vfolder host configurations, as the vfolder-host information is missing for them.

Let's update the implementation as follows:

  • If the host path of an unmanaged vfolder contains a known vfolder host's mount path, let's follow the configuration of the matched vfolder host.
  • Otherwise, let's introduce a concept of "ghost vfolder host", which provides a default set of vfolder-host permission configurations.
@achimnol achimnol added type:bug Reports about that are not working comp:manager Related to Manager component comp:storage-proxy Related to Storage proxy component urgency:4 As soon as feasible, implementation is essential. labels Jun 19, 2024
@achimnol achimnol added this to the 24.09 milestone Jun 19, 2024
@achimnol achimnol removed the type:bug Reports about that are not working label Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:manager Related to Manager component comp:storage-proxy Related to Storage proxy component urgency:4 As soon as feasible, implementation is essential.
Projects
None yet
Development

No branches or pull requests

1 participant