Bug 2189691

Summary: glance image-create-via-import leaves image in queued status
Product: Red Hat OpenStack Reporter: aruffin <aruffin>
Component: openstack-glanceAssignee: Cyril Roelandt <cyril>
Status: ASSIGNED --- QA Contact: msava
Severity: medium Docs Contact: Andy Stillman <astillma>
Priority: medium    
Version: 16.1 (Train)CC: aruffin, athomas, cyril, dhill, eglynn
Target Milestone: gaKeywords: Triaged
Target Release: 16.1 (Train on RHEL 8.2)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 1 Cyril Roelandt 2023-04-26 16:02:41 UTC
In 16.1, you need to configure a staging area where glance can write the contents of your image. See https://docs.openstack.org/glance/train/admin/interoperable-image-import.html for complete information, but basically you should have the following line in your glance config:

node_staging_uri=file:///some/path

Otherwise it will default to file:///tmp/staging/ .

You need to make sure /tmp/staging is a filesystem shared between all glance-api nodes, that is both readable and writable.


If this does not help, please:

1) Give us your config
2) Give us your logs

This can done thanks to sosreports.

Comment 5 aruffin@redhat.com 2023-05-03 14:57:47 UTC
Reposting description publicly:

Description of problem:
Customer attempts to import images into glance via the image-create-via-import flag.

glance image-create-via-import --architecture x86_64 --disk-format qcow2 --container-format bare --name test_download --visibility public --import-method web-download --progress --uri <URI to ISO>

This results in the image being stuck in a "queued" status (in some cases, for a few months unless deleted).
We have tried importing images stored within their networks as well as remotely on Openstack.org.  In all cases the image-create-via-import flag is used, the image is assgined an ID, but the status remains "queued".

We deleted all but one of the queued images and took a different approach. We broke out the effort into two different steps.
1. download the image via wget to the node's local file system.
2. Import into glance via "openstack image create" command with the --file option instead.

This seem to get the cirros image we tested with imported quickly and transitioned the other image from queued to importing status (where it still remains a day later).
 
Customer would like to understand why the image-create-via-import leaves the image stuck in queued status 

Version-Release number of selected component (if applicable):
OSP16.1

How reproducible:


Steps to Reproduce:
1. glance image-create-via-import --architecture x86_64 --disk-format qcow2 --container-format bare --name csrv_cdaf_test --visibility public --import-method web-download --uri https://download.fedoraproject.org/pub/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2


Actual results:
Image is assigned a UUID, but is stuck in queued status

Expected results:
Image downloads and imports into customer's glance directly from remote URL

Additional info:

Comment 6 aruffin@redhat.com 2023-07-07 17:12:05 UTC
Customer managed to shutdown all the redundant glance containers, leaving one glance container running.

After this, they updated the node_staging_uri parameter to a location owned, readable, and writable by the root user.  The root user seems to be the user running glance as well.

Customer attempted to download and import the image with the image-create-via-import flag which should do this as one command.  However, the image remains in a queued state.

I have requested glance config files and logs. I will attach as I receive them.



Customer would also like to know if there is a workaround that will downloading an image and import into glance via a single command as a workaround