Red Hat Bugzilla – Bug 1243829
overcloud image upload creates duplicate images
Last modified: 2015-10-08 08:15:07 EDT
Description of problem: When running "openstack overcloud image upload" more than once, we create duplicate images, even if the local image files are unmodified: Version-Release number of selected component (if applicable): I'm running oscplugin from git @ 11bd32adf86b9bf0fb488fb16b49d38033f79440 but the issue affects all currently packaged versions too AFAICT. How reproducible: Always Steps to Reproduce: [stack@instack ~]$ glance image-list +--------------------------------------+------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+------------------------+-------------+------------------+----------+--------+ | a45c40e8-9fb2-4107-adf3-dafb9065c71f | bm-deploy-kernel | aki | aki | 5026624 | active | | a9297bfd-9967-42ef-a474-bcfa1b3168bd | bm-deploy-ramdisk | ari | ari | 58822452 | active | | 04322d2c-60de-41ce-89b2-bab4e5c344db | overcloud-full-initrd | ari | ari | 33613984 | active | | 8c8be470-9203-47bf-b8c1-21286bf2ff54 | overcloud-full-vmlinuz | aki | aki | 5026624 | active | +--------------------------------------+------------------------+-------------+------------------+----------+--------+ [stack@instack ~]$ openstack overcloud image upload [stack@instack ~]$ glance image-list +--------------------------------------+------------------------+-------------+------------------+-----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+------------------------+-------------+------------------+-----------+--------+ | a45c40e8-9fb2-4107-adf3-dafb9065c71f | bm-deploy-kernel | aki | aki | 5026624 | active | | 6ea23338-edf2-4987-b15b-b9ea9912000c | bm-deploy-kernel | aki | aki | 5026624 | active | | a9297bfd-9967-42ef-a474-bcfa1b3168bd | bm-deploy-ramdisk | ari | ari | 58822452 | active | | 0aaa4c24-78c4-4635-8793-48045a30e512 | bm-deploy-ramdisk | ari | ari | 58822452 | active | | 4f3155d5-26cd-4da1-abfd-c7ea1320f3c9 | overcloud-full | qcow2 | bare | 978059264 | active | | 04322d2c-60de-41ce-89b2-bab4e5c344db | overcloud-full-initrd | ari | ari | 33613984 | active | | a4b52eec-589a-455c-b12c-0303da4024af | overcloud-full-initrd | ari | ari | 33613984 | active | | 8c8be470-9203-47bf-b8c1-21286bf2ff54 | overcloud-full-vmlinuz | aki | aki | 5026624 | active | | 53319340-f510-4442-ab60-1a705c7f6fc6 | overcloud-full-vmlinuz | aki | aki | 5026624 | active | +--------------------------------------+------------------------+-------------+------------------+-----------+--------+ Actual results: Duplicate images created Expected results: I expected one of the following: 1. Just upload the missing overcloud-full qcow image 2. Look at the images and only update those which have been modified. I wasn't sure if we had (2) implemented, but that's the way the devtest TripleO scripts work, so probably good to replicate IMO. I manually removed the overcloud-full image because I knew my local image was modified, but I didn't expect all the other images to end up duplicated.
One possible approach will be for the CLI to do a check to see if an image already exists with the name and fail if it does. We can offer a flag to overwrite the existing image if found which would delete the existing first (assuming glance doesn't have its own sort of overwrite flag). Ultimately, I could see a use in storing multiple versions of an image for upgrade purposes, but quite a bit of the rest of the workflow would need to change for that to make sense.
*** Bug 1244139 has been marked as a duplicate of this bug. ***
Latest version looks like this: $ openstack overcloud image upload Image "overcloud-full-vmlinuz" is up-to-date, skipping. Image "overcloud-full-initrd" is up-to-date, skipping. Image "overcloud-full" is up-to-date, skipping. Image "bm-deploy-kernel" is up-to-date, skipping. Image "bm-deploy-ramdisk" is up-to-date, skipping. Image file "/httpboot/discovery.kernel" is up-to-date, skipping. Image file "/httpboot/discovery.ramdisk" is up-to-date, skipping. Updating images is a different matter and wasn't tested here. If that does not work it will need a new bug.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:1862