...
message ContentTree { // previously known as (PKA) “message Image”
UUIDandVersion uuidandversionstring contentTreeID // UUID
string dsId // effectively pointer/key into dsConfigs
...
message Volume { // previously known as (PKA) “message Drive”
UUID string volumeID // UUID uuid
string contentStoreId (can be null) // used to be Image: root of the blob tree required to
...
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.
...
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.
...
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.
...