The layout of images, volumes, etc has evolved organically in EVE with things being slightly different for VM images and containers. Due to some new requirements we should create a new, consistent layout.
This layout change will be accompanied by code in the upgradeconverter to preserve existing VM volumes for already deployed applications.
New requirements
- The new API for volumes means that volumes will be identified by a volume UUID (and a generation counter). To date they are identified by the app instance UUID plus the sha256 of the image used to create them (and a generation/purge counter).
- By default it makes sense to keep the volumes in an encrypted filesystem/directory, but some applications which need extra performance should be deployable without encryption.
- The volumes created from containers should be kept in an encrypted partition.
- While keeping credentials in a VM image or container is a very bad idea, when the image/container is downloaded from a controlled enterprise-local datastore that could be the case. Thus ContentAddressableStorage as well as the directories used by the downloader and verifier to store things on disk/flash should be encrypted.
In addition, we want to remove the differences in location and naming between containers and VM images.
We also want to make it more clear which agent owns particular directories from a defense-in-depth and storage management perspective.
New layout
/persist/vault - encrypted top-level directory for the parts needing encrypted
/persist/novault - alternative for the parts not needing encryption (currently this is only proposed for volumes where encryption incurs some overhead for running ECOs).
Volumes
In /persist/vault/volumes/ and /persist/novault/volumes
The naming of the volumes will be <volumeUUID>#<generation counter> for VM and container-based ones.
Thus /persist/img and /persist/runx/pods/prepared will move into this directory
Volumes which should not be encrypted (TBD: we need to add a boolean to the volume config API for that) will be placed in /persist/novault/volumes
Content addressable storage
In /persist/vault/case
TBD: describe naming convention used; I assume we will use the naming convention used by containered
TBD: Will all of /persist/containerd move here?
Temporary persist files during download
All of /persist/vault/downloader will be owned by downloader. volumemgr will be accessing it to measure and report on disk utilization.
The internal structure of it can change over time, but they are likely to be named using Image UUIDs and/or the claimed sha256 of the objects being downloaded.
This replaces /persist/downloads/*/pending. There is probably no reason to keep the object type in the directory names.
Verifier files
The verifier will own (and be the only one with write access to) /persist/vault/verifier/
This includes the files currently undergoing verification (currently in /persist/downloads/*/verifier) and the output which has completed verification (currrently in /persist/downloads/*/verified).
The internal structure of it can change over time, but the undergoing files are likely to be named using the Image UUID and/or the claimed sha256, while the completed files are likely to be named using just the sha256.
Thus this replaces /persist/downloads/*/{verifier,verified). There is probably no reason to keep the object type in the directory names.
Upgradeconverter
At boot upgradeconverter will look for files in /persist/img/ and extract the old and new configuration from /persist/checkpoint/config to get both the volume UUIDs and volumeReg, and the Drive information from the app instance configuration. That is sufficient to determine which volume UUID is used by which app instance, hence convert the filename as part of moving the files from /persist/img to /persist/vault/volumes
TBD: should we do the same for /persist/runx/pods/prepared? Currently these get re-created on each device reboot due to a bug in the code.