Description of problem: I uploaded an image to glance and waited for a really long time. The GUI still showed the image in "saving" status... To see if this is also happening from the command line, I tried a 'glance image-create' command and it returned an error almost immediately: Error finding address for http://192.0.2.9:9292/v1/images: [Errno 32] Broken pipe The GUI never fails (it's been running here for ~3 hours) and the GUI user doesn't have a chance to know that there is a problem. Version-Release number of selected component (if applicable): python-django-horizon-2015.1.0-10.el7ost.noarch How reproducible: When the glance service is unresponsive Steps to Reproduce: 1. Make sure glance doesn't handle any requests. It happened to me after a power outage and we're still investigating why exactly glance was stuck. 2. Log in to horizon 3. Upload an image Actual results: The upload never progresses at all
Liberty has no feature added, I believe we'll benefit from a notification mechanism, hopefully added during mitaka dev cycle.
I could reproduce this by: - Filling the new image form and saving it - While the image is being saved, kill all glance services over and over Result: Image is in saving status. I dont know if this is an horizon issue. The image returned from glance directly has that status on my test so horizon is just showing what glance returns, its not making any decisions on whats in there or what status is on the image. [root@openstack ~(keystone_admin)]# glance image-show a0e380bc-4ad9-4836-af97-715eed3d33b3 +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | None | | container_format | bare | | created_at | 2016-04-22T11:26:32Z | | description | | | disk_format | iso | | id | a0e380bc-4ad9-4836-af97-715eed3d33b3 | | min_disk | 0 | | min_ram | 0 | | name | fghfg | | owner | 5e81561e7475442986c28910989e0081 | | protected | False | | size | 277872640 | | status | saving | | tags | [] | | updated_at | 2016-04-22T11:26:32Z | | virtual_size | None | | visibility | private | +------------------+--------------------------------------+ So from my point of view, the problem does _not_ lie in horizon, it is on glance. The image saving action was cut and the image is stuck in that status forever, when it should go to error. Would be good to get a comment on this, as looks to me a NOTABUG
The difference is that you interrupted an upload while it was saving, and indeed you can open a bun on glance with this scenario. In the original bug, glance behaved ok by immediately returning an error, and in horizon the status was shown incorrectly. But it's hard to recreate such a situation.
Understood, any hint on how I could reproduce this? What was the issue with glance in that installation, so I may be able to reproduce this manually by breaking glance.
It broke as a result of a power outage, which is difficult to reproduce. You can try breaking glance in some other way(s), like misconfiguring the service or disconnecting its backend etc... I also googled for the error message "[Errno 32] Broken pipe" and found several bugs on glance that cause this error, but I couldn't deduce what the scenario was to recreate them also. I'm sorry that I don't have a more exact answer.
• not clear how to reproduce • might benefit from general hardening of the glance status handling • needs to be worked on upstream
OSP11 is now retired, see details at https://access.redhat.com/errata/product/191/ver=11/rhel---7/x86_64/RHBA-2018:1828