| Design document | |
|---|---|
| Revision | v1 |
| Status | proposed |
| Review | create new issue |
“Patches” are signed binary blobs which can be queried and applied.
They are stored in the dom0 filesystem under /var/patch. Unfortunately
the patches can be quite large – imagine a repo full of RPMs – and
the dom0 filesystem is usually quite small, so it can be difficult
to upload and apply some patches.
Instead of writing patches to the dom0 filesystem, we shall write them to disk images (VDIs) instead. We can then take advantage of features like
VDI.copyto manage the patches.
Add a field pool_patch.VDI of type Ref(VDI). When a new patch is
stored in a VDI, it will be referenced here. Older patches and cleaned
patches will have invalid references here.
The HTTP handler for uploading patches will choose an SR to stream the
patch into. It will prefer to use the pool.default_SR and fall back
to choosing an SR on the master whose driver supports the VDI_CLONE
capability: we want the ability to fast clone patches, one per host
concurrently installing them. A VDI will be created whose size is 4x
the apparent size of the patch, defaulting to 4GiB if we have no size
information (i.e. no content-length header)
pool_patch.clean_on_host will be deprecated. It will still try to
clean a patch from the local filesystem but this is pointless for
the new VDI patch uploads.
pool_patch.clean will be deprecated. It will still try to clean a patch
from the local filesystem of the master but this is pointless for the
new VDI patch uploads.
pool_patch.pool_clean will be deprecated. It will destroy any associated
patch VDI. Users will be encouraged to call VDI.destroy instead.
pool_patch records will only be deleted if both the filename field
refers to a missing file on the master and the VDI field is a dangling
reference
Patches stored in VDIs will be stored within a filesystem, like we used
to do with suspend images. This is needed because (a) we want to execute
the patches and block devices cannot be executed; and (b) we can use
spare space in the VDI as temporary scratch space during the patch
application process. Within the VDI we will call patches patch rather
than using a complicated filename.
When a host wishes to apply a patch it will call VDI.copy to duplicate
the VDI to a locally-accessible SR, mount the filesystem and execute it.
If the patch is still in the master’s dom0 filesystem then it will fall
back to the HTTP handler.