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.
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.
/persist/vault is the encrypted top-level directory for the parts needing encryption. This will be encrypted using a key sealed under the PCRs in the TPM, thus must not be used to store information which the device needs to access in order to be able to perform remote attestation with the controller.
/persist/clear is an alternative for the parts not needing encryption (currently this is only proposed for volumes where encryption incurs some overhead for running ECOs). Using that requires the addition of a boolean to the EVE API to specify unencrypted storage for the volume.
/persist/unsealed-vault is a future location which will be encrypted using a key stored in the TPM but not sealed under the PCRs. In the future we can move things which are needed during a post-update boot before re-attestation to this unsealed vault, such as /persist/status/nim/DevicePortConfigList/ which keeps the network configuration across device reboots.
Under those three directories we will in principle have sub-directories as follows, but the use of the future /persist/unsealed-vault is TBD.
In /persist/vault/volumes/ and /persist/clear/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/clear/volumes
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?
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.
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.
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.