Volume (and Content) device API
...
message ContentTree { // previously known as (PKA) “message Image”
UUIDandVersion uuidandversion string contentTreeID // UUID
string dsId // effectively pointer/key into dsConfigs
string URL URLsuffix // PKA name - added to the datastore URL
Format iformat // RAW, QCOW2, CONTAINEROCI, BLOB_TREE,
...
message Volume { // previously known as (PKA) “message Drive”
UUID uuidstring volumeID // UUID uuid
volumeContentOrigin origin
string contentStoreId (can be null)VolumeAccessProtocols protocols[] // used to be Image: root of the blob tree required todescribes all the different ways how this Volume can
// construct this Volume
VolumeType voltype // describes the type of the Volume and thus how to construct it
// out of the contentSoreID blobs (PKA DriveType)
VolumeAccessProtocols protocols[] // describes all the different ways how this Volume can
// be offered to Tasks (9p, nfs, be offered to Tasks (9p, nfs, scsi, ata, virtio, etc.)
int64 [re]generationCount
...
google.protobuf.Timestamp createTime = 1;
uint refCount = 2;
google.protobuf.Timestamp lastUseTime lastRefcountChangeTime = 3; // When refCount dropped to zerolast changed
}
Content Origin
Presumably we will have this to parallel the configuration.
...
volumeContentOriginType type = 1; volumeDownloadOrigin download = 2;
VolumeType voltype // describes the type of the constructed volume (note that "EMPTY" is not used; that is the "BLANK" type)
string downloadContentStoreID = 2; // where we get DOWNLOAD types from
// TBD More optional fields for other originTypes
}
message volumeDownloadOrigin {
string datastoreID = 1; // UUID string
string URLsuffix = 2; // what to append to the datastore URL
string sha = 3; // Either specified in config or determined from registry
}
Putting it together
message ZInfoVolume {
...
As we add support to the controller and EVE we will go through the following steps:
- Today: old EVE, old controller.
- Phase1: old EVE, new controller. Controller is sending both Volume and Drive for the appInstanceConfig.
- Phase2: new EVE, new controller.
The new EVE will upgrade the schema for /persist/img on first boot by using the checkpointed protobuf message from before the reboot.
- Phase 3: new EVE, cleaned up controller. Controller will no longer send Drive in appInstanceConfig; only sending Volume
NOTE If there is a downgrade of EVE during phase2 to an old EVE (which does not support the new schama for /persist/img) the volumes in /persist/img will not be used which can be disruptive for deployed applications.
Considered and rejected ideas
...
Currently the controller implicitly asks EVE to create volumes by the Drive in the API. There are different ways the controller might transition to using volumes for existing, deployed application instances:
- The controller takes the current Zededa manifest for the application and extracts the drive/image information and uses that to create a Volume object in the controller (with a UUID) and sends that as part of the EVE configuration. Hence even for existing applications there will be explicit volumes with UUIDs.
- The controller continues to use the Drive message in the API to specify volumes for existing application instances, while new ones use the Volume object. In that case there will be no UUID associated with the volumes implicitly specified by the Drive protobuf message.
If we need to support the second approach in EVE, then we will have volumes which are created implicitly as part of deploying an app instance do not have a volumeID, but can be identified by a combination of the App Instance UUID and the Image UUID (which we might want to rename to “Content Tree UUID”). The content tree in turn might refer to a datastore, have some relative URL/name in that datastore, and any given use of that content tree will have a hash which uniquely identifies it.
...