[glance] import RBD image

Erno Kuvaja ekuvaja at redhat.com
Mon Apr 4 13:43:03 UTC 2022

On Mon, Mar 28, 2022 at 6:16 PM Tony Liu <tonyliu0592 at hotmail.com> wrote:

> Thank you Erno for pointing it out!
> I wonder if I can get a bit more clarifications.
> ```
> [image_import_opts]
> image_import_plugins = ['image_decompression', 'image_conversion']
> [image_conversion]
> output_format = raw
> ```
> For example, with the above configuration and web-download method,
> to download image.qcow2.gz2 (2GB) and create a raw image (40GB).
> The uncompressed image.qcow2 is 10GB.
> My understanding is that, image.qcow2.gz2 is downloaded and takes 2GB
> space.
> Then it's decompressed to image.qcow2, and 12GB space is used now.
> Then it's converted to raw image to Ceph directly. So the max space
> required for
> this process is 12GB. Is that correct?
> Not exactly.

The decompression plugin will clean the original compressed image after
itself, so it will need 12GB in your example as peak and once its work is
finished there will be left that 10GB image, the conversion plugin will do
the same. The convert to raw will utilize 50GB of disk space during it's
operation and once it's done the 40GB RAW will be in the staging. That will
then be uploaded to the destination store(s) before it's cleaned up at the
end of the Import taskflow. The reason for this is that there might be
other plugins in the chain that still need to have access to that image
data before it's sent to the store.

> Regarding to recommended local staging directory, doc says "you must
> configure
> each worker with the URL by which the other workers can reach it directly".

Would you mind giving a link to that part of the doc. Sounds like it needs
little clarification. That shared access was required for the
'glance-direct' import method as the stage and import calls are different
and might land to different nodes. There was work done a couple of cycles
ago to mitigate this need and it was never a requirement for the
'web-download' method as that is processed fully on the import request.

> Is that because the image processing (download, convert, upload) may be
> split to
> different workers? I would expect the whole process/task is tied to one
> worker,
> because the process is triggered by single request from client. It would
> be good
> to get some clarifications on how this works and why workers need to
> connect
> to each other during image processing.

Initially there was discussion of executing these flows in separate
workers, but it has been never tested as no-one has expressed real need for
that. I doubt it would work as is considering how coupled some of the
import code is currently with the g-api code.

> For worker_self_reference_url, would "http://<worker IP>:<glance-api
> port>" work?

Yes, that should work.

- Erno

> Thanks!
> Tony
> ________________________________________
> From: Erno Kuvaja <ekuvaja at redhat.com>
> Sent: March 28, 2022 04:13 AM
> To: Tony Liu
> Cc: openstack-discuss
> Subject: Re: [glance] import RBD image
> On Sun, Mar 27, 2022 at 2:10 AM Tony Liu <tonyliu0592 at hotmail.com<mailto:
> tonyliu0592 at hotmail.com>> wrote:
> Hi,
> There used to be a way to import RBD image with API v1, but not any more
> with v2.
> Is there any other way to do that?
> In case given QCOW2 image, It would be much faster and easier to convert
> it directly
> to RBD image with RAW format, than convert it to RAW format on local file
> system and
> upload the RAW image to Glance.
> Thanks!
> Tony
> Hi Tony,
> There is an image-conversion plugin for Interoperable Image Import for
> that. Please see
> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html
> for the documentation.
> jokke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220404/c03385c9/attachment.htm>

More information about the openstack-discuss mailing list