Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added volumeContentOrigin in Volume; moved type to the content origin; renamed URL to URLsuffix; removed downloadContentOrigin message

Volume (and Content) device API

...

  string dsId // effectively pointer/key into dsConfigs


  string URL URLsuffix // PKA name - added to the datastore URL

  Format iformat // RAW, QCOW2, CONTAINEROCI, BLOB_TREE,

...

  string volumeID // UUID uuid

  string contentStoreId (can be null) // used to be Image: root of the blob tree required to

                                                         // construct this Volume

   

  VolumeType voltype // describes the type of the Volume and thus how to construct it

                                    // out of the contentSoreID blobs (PKA DriveType)  volumeContentOrigin origin   

  VolumeAccessProtocols protocols[] // describes all the different ways how this Volume can
                                                          // be offered to Tasks (9p, nfs, scsi, ata, virtio, etc.)

...

   google.protobuf.Timestamp createTime = 1;

   uint refCount = 2;

   google.protobuf.Timestamp lastRefcountChangeTime = 3; // When refCount last changed

...

        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

...