xenapi: soft reboot should attempt hard reboot on failure

Bug #1422342 reported by John Garbutt on 2015-02-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Medium
Unassigned

Bug Description

When we issue a soft reboot. If it fails we should then do a hard reboot.

This is for consistency with libvirt:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1977

Changed in nova:
assignee: John Garbutt (johngarbutt) → nobody

John, looking on the reboot() function:

def reboot(self, context, instance, network_info, reboot_type,
                      block_device_info=None, bad_volumes_callback=None)

There is a reboot_type parameter. For XenAPI this param is properly passed to underlying
VMOps class in nova/virt/xenapi/vmops.py which implements the reboot() for Xen.
So you can have, either proper SOFT or HARD reboot and this looks fine for me.

While in the nova/virt/libvirt/driver.py, if reboot_type=='SOFT' fails nova unconditionally
does the hard reboot what can be sometimes unexpected but at the end of the day we
want to reboot the VM.

Changed in nova:
assignee: nobody → Radoslaw Smigielski (radoslaw-smigielski)
assignee: Radoslaw Smigielski (radoslaw-smigielski) → nobody
status: Triaged → In Progress

Fix proposed to branch: master
Review: https://review.openstack.org/156417

Changed in nova:
assignee: nobody → Radoslaw Smigielski (radoslaw-smigielski)
Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx) wrote :

Please keep in progress until patch is merged

Changed in nova:
status: Fix Committed → In Progress

Change abandoned by Joe Gordon (<email address hidden>) on branch: master
Review: https://review.openstack.org/156417
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Changed in nova:
assignee: Radoslaw Smigielski (radoslaw-smigielski) → nobody

Solving an inconsistency: The bug is "in progress" but without an assignee.
I set the status back to the last known before the change to "in progress".

Changed in nova:
status: In Progress → Triaged
Changed in nova:
assignee: nobody → lyanchih (lyanchih)
Changed in nova:
assignee: lyanchih (lyanchih) → nobody
assignee: nobody → lyanchih (lyanchih)

Fix proposed to branch: master
Review: https://review.openstack.org/203513

Changed in nova:
status: Triaged → In Progress
Changed in nova:
assignee: Chung Chih, Hung (lyanchih) → nobody
status: In Progress → Confirmed
Changed in nova:
assignee: nobody → John Garbutt (johngarbutt)
status: Confirmed → In Progress

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/203513
Reason: This patch has been sitting unchanged for more than 12 weeks. I am therefore going to abandon it to keep the nova review queue sane. Please feel free to restore the change if you're still working on it.

Sean Dague (sdague) wrote :

There are no currently open reviews on this bug, changing the status back to the previous state and unassigning. If there are active reviews related to this bug, please include links in comments.

Changed in nova:
status: In Progress → Confirmed
assignee: John Garbutt (johngarbutt) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers