upgrade from diablo leaves existing images with kernel unbootable
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
Vish Ishaya |
Bug Description
After an upgrade to essex (ubuntu precise), some images registered via the ec2 api that had a kernel and ramdisk were left broken.
This was because the images were uploaded referencing a given aki-xxxxxxx and ari-xxxxxxx but after upgrade, those aki and ari changed, rendering the images broken.
I made some notes, saying:
##aki-0000009e smoser-
##ari-0000009f smoser-
#
## New (amis re-numbered after essex upgrade)
#aki-0000001e smoser-
#ari-0000001f smoser-
Subsequently, I've twice uploaded new images that reference a kernel/ramdisk that were present prior to the upgrade, and I get strange results:
$ euca-describe-
IMAGE aki-0000001e smoser-
IMAGE ari-0000001f smoser-
$ cloud-publish-
Tue Feb 28 17:55:14 UTC 2012: ====== extracting image ======
kernel : aki-0000001e
ramdisk: ari-0000001f
image : lucid-server-
Tue Feb 28 17:55:23 UTC 2012: ====== bundle/upload image ======
Tue Feb 28 17:56:18 UTC 2012: ====== done ======
emi="ami-0000006f"; eri="ari-0000001f"; eki="aki-0000001e";
$ euca-describe-
IMAGE ami-0000006f smoser-
Note, that after cloud-publish-
But
$ euca-run-instances ami-0000006f
ImageNotFound: Image 30 could not be found.
$ euca-describe-
ImageNotFound: Image aki-00000061 could not be found.
$ euca-describe-
ImageNotFound: Image ari-00000062 could not be found.
To make things even stranger, while the above happens now, soon after publish I verified that the images booted with identical 'run-instances' as above, and they did boot. Then from inside the instance, I see:
$ for p in ami-id kernel-id ramdisk-id; do echo $p: $(wget http://
ami-id: ami-00000000
kernel-id: ami-00000000
ramdisk-id: ami-00000000
It appears the last bit may be a general essex bug as I see it on even other instances.
Changed in nova: | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Vish Ishaya (vishvananda) |
Changed in nova: | |
status: | Triaged → In Progress |
Changed in nova: | |
milestone: | none → essex-rc1 |
Changed in nova: | |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | essex-rc1 → 2012.1 |
More strangeness possibly related: image-attribute ami-0000006f --launch-permission --remove all
$ euca-run-instances ami-0000006f
ImageNotFound: Image 112 could not be found.
$ euca-modify-
IMAGE ami-0000006f
$ euca-run-instances ami-0000006f
ImageNotFound: Image 114 could not be found.
Ie, making the image private, then public changes the image id of the error response.
I also realize that above, the instances I ran to verify, I did so when the image was private. Then, I made them public and they failed to run.