nova resize-revert forgets hw_cdrom_bus

Bug #1361925 reported by Michael Hudson-Doyle
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Expired
Undecided
Unassigned

Bug Description

Hi,

The test tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert fails for me on arm64. It turns out that this is because (if you use a config drive, which is the default with devstack) you need to set hw_cdrom_bus on the image to 'virtio' but the resize-revert command somehow fails to take this into account and tries to put the cdrom on the ide bus, which does not exist in the emulated machine model on arm64.

These command reproduce for me (given an image with hw_cdrom_bus set)

nova boot --poll --image $IMAGE_ID --flavor m1.tiny inst
nova resize inst m1.small --poll
nova resize-revert inst

I'll attach the libvirt log for such an instance.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :
description: updated
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

And here is the traceback from the n-cpu log: http://pastebin.ubuntu.com/8155086/

Tracy Jones (tjones-i)
tags: added: libvirt testing
Joe Gordon (jogo)
tags: added: compute
removed: testing
Revision history for this message
Sean Dague (sdague) wrote :

is this an arm specific issue? Or can it be produced on x86?

Changed in nova:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I imagine it can be reproduced in x86 to the extent that if you set hw_cdrom_bus to virtio, start an instance and abort a resize of it, it will end up using the ide bus for the cdrom after that point. Of course it's not as dramatic as on arm/arm64 because the instance doesn't die...

Revision history for this message
Markus Zoeller (markus_z) (mzoeller) wrote : Cleanup EOL bug report

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY

Changed in nova:
importance: Low → Undecided
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.