On Mon, Dec 20, 2021 at 11:04:16AM +0100, Laszlo Ersek wrote:
- AND we can confirm if the "actual sizes" are actually
useful for *all*
output plugins different from the old rhv output. The whole thing is
being done for the old rhv output's sake -- if neither "rhv-upload"
nor "vdsm" (= the other two OVF-creating output plugins) need the
actual disk sizes, then the actual list construction should be unique
to "output/output_rhv_upload.ml".
I'm fairly sure this only needs to be done for -o rhv. For sure not
-o rhv-upload, and I'm fairly sure but not 100% about -o vdsm.
implied that fetching the extent map was safe during finalization.
The
rhv-upload output plugin does not conform to that invariant however.
This I feel is generally a problem with rhv-upload-plugin (also that
it doesn't support extents at all), but it's not something we need to
fix right now if we don't have to fetch the extent map.
One possible solution being discussed off list was to move
rhv-upload-plugin to nbdkit ("nbdkit-imageio-plugin"), and at the same
time make it auto-renew the ticket and add extents support, so it
behaves more like an nbdkit plugin. That could solve the other
problem (ticket expiring if there is a delay on the input side).
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top