Volume Manager Usecases

Owned by Roman Shaposhnik
Last updated: Jun 08, 2020
2 min read

This page is a collection of use cases for the new Volume Manager design. These usecases are expected to be prioritized and ultimately marked as either "rejected" or "implemented". Every use-case is meant to have a description, rationale and proposed chunk of EVE config

Create a 9p accessible volume out of OCI image (partially implemented)

  • As a user of containers, I want multiple POSIX filesystems to be mounted within my running container

  • This is currently only possible for the root of the OCI container and requires the following EVE stanza:
       XXX
    We need to implement support so that  any number of OCI images can be attached to a running container

Create a BLOCK accessible volume out of disk image (partially implemented)

  • As a user of containers, I want multiple POSIX filesystems to be mounted within my running container

  • This is reverse of the previous item: it is currently only possible for the non-root of the OCI container and requires the following EVE stanza
        XXX
    It would be nice to implement support for this as well, but this is not as important as the previous item

Create a BLOCK accessible volume out of OCI image (not implemented)

  • As a user of VMs I would like my VMs disk image to be packaged in the OCI container

  • This is currently NOT implemented and requires some additional thinking about the schema for the OCI image

For every type of Volume and Context tree we need to be able to specify if it is to be encrypted or not (not implemented)

  • As a user that is deploying VMs I need to be able to prioritize security vs. performance on an app-per-app basis

  • This is currently NOT implemented and requires some additional thinking about both Volumes and Content Trees

Transition BaseOS update workflow to leverage volume mechanisms (not implemented)

  • As a maintainer of EVE instance, I'd like complete flexibility as to how I update rootFS from bits that are available to me as content.
    The may require us to introduce yet another type of Volume called RootFS. Once we do that, the rest of the operations becomes completely transparent and fold very nicely into the Volume flows

  • This is currently NOT implemented and requires some additional thinking about the schema for the OCI image