glance image-update --file does not work correctly

Bug #1220104 reported by JunJie Nan on 2013-09-03
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Glance Client

Bug Description

Steps to reproduce the problem:
1. Create image
glance image-create --file RHEL64-x86_64-cfntools.qcow2 --disk-format qcow2 --container-format bare --name RHEL64-x86_64-cfntools
2. Modify RHEL64-x86_64-cfntools.qcow2,
3. Update image (say the image id is 7ecfb91e-0806-408a-a189-1e34353afc35)
glance image-update --file RHEL64-x86_64-cfntools.qcow2 7ecfb91e-0806-408a-a189-1e34353afc35
4. Launch an instance to check whether the image content updated

Expected result:
The image should be updated to the modified version
Actual result:
The image is not updated to the modified version.

Why I update the disk content of an image, instead of delete the image and create new one?

I want to keep the image id and image name no change, so my update will not break end users using the image.

JunJie Nan (nanjj) on 2013-09-03
description: updated
liuan (liuanaqi) on 2013-09-07
Changed in glance:
assignee: nobody → liuan (liuanaqi)
JunJie Nan (nanjj) wrote :

Looks it's python-glanceclient issue

affects: glance → python-glanceclient
Changed in python-glanceclient:
assignee: liuan (liuanaqi) → nobody
importance: Undecided → Medium
status: New → Triaged
Changed in python-glanceclient:
assignee: nobody → Cindy Pallares (cindy-pallaresq)
Changed in python-glanceclient:
assignee: Cindy Pallares (cindy-pallaresq) → nobody
Hao Li (lihaosz) on 2015-03-04
Changed in python-glanceclient:
status: Triaged → Fix Released
Xiang Hui (xianghui) wrote :

Hi Hao Li,

Could you specify the release Milestone and point the patch which fix this issue to help people to find where it is, and it may need backport and build to the corresponding package.


Xiang Hui (xianghui) wrote :


If someone could revert the status to 'triage' before the patch is linked or a place pointed out where fixed it ?


Pablo (pcaruana) wrote :

This bugzilla has several weak points in the tacking workflow. Currently nobody has assigned. is still marked as Fix Released without poiting the milestone or the patch itself

At least on old icehouse the result of the reported command is unfortunate, as it doesn't provide enough feedback to the user about what's happening.

However, the real motivation of the "misfunctioning" command is that images are immutable resources and once you create them, you can't modify them.

this changes in v2 a bit since you can now upload the image yourself and add more remote locations, although not recommended. Users have always be encouraged to treat images as unique, immutable resources.

A workaround for this may be to use image names instead of image ids. Whenever an image wants to be updated, re-use the image name and delete/rename the previous one.

Is this something other people are willing to do?

At that time y no recommended way to do this other than update the images by creating new ones. One reason is that uploading a new image may require changing the checksum (which some users rely on), the size of the image, etc. All these can lead to inconsistencies in user environments and across the cloud, hence images are immutable.

Let's hear other opinions.

YF (yf-9186) on 2019-03-22
information type: Public → Private
information type: Private → Public
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers