Skip to content
This repository was archived by the owner on Aug 2, 2023. It is now read-only.

Virtual folder API #28

Closed
7 tasks done
achimnol opened this issue Feb 14, 2017 · 3 comments
Closed
7 tasks done

Virtual folder API #28

achimnol opened this issue Feb 14, 2017 · 3 comments

Comments

@achimnol
Copy link
Member

achimnol commented Feb 14, 2017

Provide a virtual folder API. Users can create virtual folders with limited storage and mount them when launching kernel sessions by passing the list of virtual folders via options.

  • Write an initial master-agent negotiation step to get mount information
    • This is done via etcd.
  • Test mounting mounted SMB volumes into docker containers
    • This works like a charm with Azure FileShare storage.
  • Test mounting mounted NFS volumes into docker containers
  • Configurations (separate NFS host or a local root directory)
  • CRUD of virtual folder instances with a database schema
    • Each folder has a unique ID, filesystem alias, ownership and ACL, size/file limits.
    • Filesystem alias cannot start with dots.
    • sorna-agent should skip mounted virtual folders when uploading output files in /home/work of kernel containers
  • Deploy a backend NFS/SMB server - later, we would migrate to Amazon EFS or other similar NFS-compatible storage services for scalability
    • How could we dynamically mount/unmount subtree of the NFS? Fuse?
    • The NFS server itself may use the standard kernel-side NFS daemon, but should use a separate EBS volume for ease of management and backups.
    • UPDATE: This is done using Azure File Share. It has some latency due to geographic distances, so later we will revisit for performance optimization using closer locations if available.
  • Implement mounting of virtual folders to agent instances and kernels
    • We should keep each virtual folder exclusively mounted. (not shared among multiple kernels even for a single user) -- release this limitation later? (it's NFS's responsibility to keep filesystem consistency anyway)
    • Filesystem-level synchronization should be handled by the NFS/SMB server.
@achimnol achimnol added this to the Bank milestone Feb 14, 2017
@achimnol
Copy link
Member Author

Let's consider using Alluxio

achimnol added a commit to lablup/backend.ai that referenced this issue May 16, 2017
achimnol added a commit that referenced this issue Aug 23, 2017
 * Now manager + gateway runs on multiple CPU cores with sane
   transaction semantics.  Thanks to aiotools!

   - It no longer depends on Redis as a pub-sub broker nor a database.
     All communications are done via ZeroMQ with no centralized queue
     server.

   - Redis is used only for per-keypair rate-limiting.

 * Now the manager searches available agent to spawn new containers
   based on available memory / CPU / GPU capacity units.
   No more hard-coded instance types!

 * The db schema is now prepared for multi-container kernel sessions.

   - User-facing APIs now use "session ID" which is directed to the
     master container of the given session.

   - Each container has unique "kernel ID" and managed individually.

 * Replace asyncpg + asyncpgsa with aiopg for better SQLAlchemy
   supports (especially custom type decorators).

 * TODOs

   - Stabilize accounting of used/available resource units.

   - Still some parts are confused of session/kernel IDs...
@achimnol
Copy link
Member Author

@achimnol
Copy link
Member Author

achimnol commented Mar 8, 2018

Marking this as done — extension will be separate issues.

@achimnol achimnol closed this as completed Mar 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant