Hide Forgot
Description of problem: - glance image entry gets store in the db even "image-create" operation failed. Version-Release number of selected component (if applicable): RHOS8 How reproducible: 100% Steps to Reproduce: 1. change selinux context of "/var/lib/glance/images/" 2. make sure selinux is in enforcing mode. 3. try to upload image 4. operation will fail. But entry of the image will be stored in the glance DB. [root@rhos8-beta9 ~(keystone_admin)]# mount |grep -i glan xx.xx.xx.xx:/home/rhos8_glance on /var/lib/glance/images type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=xx.xx.xx.xx,local_lock=none,addr=xx.xx.xx.xx) [root@rhos8-beta9 ~(keystone_admin)]# ls -lhdZ /var/lib/glance/images/ drwxrwxrwx. glance glance system_u:object_r:nfs_t:s0 /var/lib/glance/images/ [root@rhos8-beta9 ~(keystone_admin)]# glance image-create --name cirros --container-format bare --disk-format qcow2 --file cirros.qcow2 --progress [=============================>] 100% +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | None | | container_format | bare | | created_at | 2016-04-15T14:17:52Z | | disk_format | qcow2 | | id | d004ce26-6e7c-4699-91dd-908b2435b2fc | | min_disk | 0 | | min_ram | 0 | | name | cirros | | owner | af930979147d4729975c2e58bb891936 | | protected | False | | size | None | | status | queued | | tags | [] | | updated_at | 2016-04-15T14:17:52Z | | virtual_size | None | | visibility | private | +------------------+--------------------------------------+ 503 Service Unavailable: Insufficient permissions on image storage media: Permission to write image storage media denied. (HTTP 503) <== [root@rhos8-beta9 ~(keystone_admin)]# glance image-list +--------------------------------------+--------+ | ID | Name | +--------------------------------------+--------+ | 050c8f00-5a67-48aa-ab3e-26d4e8c6775a | cirros | | d004ce26-6e7c-4699-91dd-908b2435b2fc | cirros | <== | abdc2442-a04f-45f5-8c1b-003406cb6564 | rhel | +--------------------------------------+--------+ [root@rhos8-beta9 ~(keystone_admin)]# ls /var/lib/glance/images/ 5751669c-8b3c-4edb-a05e-a5699a8ebb9e abdc2442-a04f-45f5-8c1b-003406cb6564 [root@rhos8-beta9 ~(keystone_admin)]# grep -i den /var/log/audit/audit.log [...] type=AVC msg=audit(1460729872.784:35233): avc: denied { search } for pid=19431 comm="glance-api" name="rhos8_glance" dev="0:41" ino=248 scontext=system_u:system_r:glance_api_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir Actual results: glance image entry gets store in the db even "image-create" operation failed. Expected results: if image-create operation is failing then, glance should not make entry in glance DB. Additional info:
I'd say the image entry should exist but the image status should be killed, which is the current behavior for other failures. To be honest, I'd have expected this failure to trigger that status change.
Flavio: this is true in v1 (see https://github.com/openstack/glance/blob/stable/liberty/glance/api/v1/upload_utils.py#L242): the status of the image is changed to 'killed'. In v2, though, this is not the case. We just set the status to 'queued' (see https://github.com/openstack/glance/blob/stable/liberty/glance/api/v2/image_data.py#L181 and https://github.com/openstack/glance/blob/stable/liberty/glance/api/v2/image_data.py#L49). Apparently, the 'killed' status is being deprecated in v2 (see https://github.com/openstack/glance/blob/stable/liberty/glance/domain/__init__.py#L105), so I'm not too found of doing the same as in v1. Flavio, WDYT?
To be clear, I'm afraid that changing the status might prevent us from doing stuff like: $ glance image-upload --file cirros.qcow2 IMAGE_ID in order to fix the image once the permission issue has been solved.
Not a z-stream material.
This behavior is as expected. The Glance image creation is two call process where we first create the image record (the queued image) and that transitions to active after the data has been uploaded with image-upload. glanceclient can streamline these two commands when user gives it also the bits to upload during the image-create command (similar behavior as with v1 client). If no data has been uploaded (like in this described case) and associated with the image record, we have no reason to kill or delete the image upon upload failure, thus the image is left to queued state so that the error which occurred can be corrected and the data can be uploaded to the image.
(In reply to Erno Kuvaja from comment #6) > This behavior is as expected. > > The Glance image creation is two call process where we first create the > image record (the queued image) and that transitions to active after the > data has been uploaded with image-upload. glanceclient can streamline these > two commands when user gives it also the bits to upload during the > image-create command (similar behavior as with v1 client). If no data has > been uploaded (like in this described case) and associated with the image > record, we have no reason to kill or delete the image upon upload failure, > thus the image is left to queued state so that the error which occurred can > be corrected and the data can be uploaded to the image. Thanks for the information. Can we remove the entry after informative message ? like: - if `glance image-create` fails due to some reason, it should throw error behind failure and remove the entry from the failed image entry. >> 503 Service Unavailable: Insufficient permissions on image storage media: Permission to write image storage media denied. (HTTP 503) <== Glance currently give informative message. Can we remove the image entry after above error message. For ex: <snip> 503 Service Unavailable: Insufficient permissions on image storage media: Permission to write image storage media denied. (HTTP 503). Deleting the image from image database. </snip>
(In reply to Pratik Pravin Bandarkar from comment #7) > (In reply to Erno Kuvaja from comment #6) > > This behavior is as expected. > > > > The Glance image creation is two call process where we first create the > > image record (the queued image) and that transitions to active after the > > data has been uploaded with image-upload. glanceclient can streamline these > > two commands when user gives it also the bits to upload during the > > image-create command (similar behavior as with v1 client). If no data has > > been uploaded (like in this described case) and associated with the image > > record, we have no reason to kill or delete the image upon upload failure, > > thus the image is left to queued state so that the error which occurred can > > be corrected and the data can be uploaded to the image. > > Thanks for the information. Can we remove the entry after informative > message ? like: > - if `glance image-create` fails due to some reason, it should throw error > behind failure and remove the entry from the failed image entry. > > >> 503 Service Unavailable: Insufficient permissions on image storage media: Permission to write image storage media denied. (HTTP 503) <== > > Glance currently give informative message. Can we remove the image entry > after above error message. > > For ex: > > <snip> > 503 Service Unavailable: Insufficient permissions on image storage media: > Permission to write image storage media denied. (HTTP 503). Deleting the > image from image database. > </snip> Thanks for the information. Can we remove the entry after informative message ? like: - if `glance image-create` fails due to some reason, it should throw error behind failure and remove the failed image from the image list. >> 503 Service Unavailable: Insufficient permissions on image storage media: Permission to write image storage media denied. (HTTP 503) <== Glance currently give informative message. Can we remove the image entry after above error message. For ex: <snip> 503 Service Unavailable: Insufficient permissions on image storage media: Permission to write image storage media denied. (HTTP 503). Deleting the image from image database. </snip>
Hi Pratik, Sorry for late reply, totally missed your follow up question. You can issue image-delete after the error to remove the image. - Erno