[Bug 1748280] Re: 'nova reboot' on arm64 is just 'nova reboot --hard' but slower
balint.reczey at canonical.com
Wed Feb 14 08:31:40 UTC 2018
This looks like breaking autopkgtest, at least for unattended-upgrades:
autopkgtest [05:40:32]: test test-systemd.py: [-----------------------
bash: line 1: 5110 Killed /tmp/autopkgtest.wwbI8q/build.hcW/src/debian/tests/test-systemd.py 2> >(tee -a /tmp/autopkgtest.wwbI8q/test-systemd.py-stderr >&2) > >(tee -a /tmp/autopkgtest.wwbI8q/test-systemd.py-stdout)
autopkgtest [05:40:32]: test process requested reboot with marker InstallOnShutdown
autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds...
File missing : /var/log/unattended-upgrades/unattended-upgrades.log
InstallOnShutdown did not run
autopkgtest [05:41:03]: test test-systemd.py: -----------------------]
autopkgtest [05:41:04]: test test-systemd.py: - - - - - - - - - - results - - - - - - - - - -
test-systemd.py FAIL non-zero exit status 1
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to nova in Ubuntu.
'nova reboot' on arm64 is just 'nova reboot --hard' but slower
Status in nova package in Ubuntu:
Within Canonical's multi-architecture compute cloud, I observed that
arm64 instances were taking an unreasonable amount of time to return
from a 'nova reboot' (2 minutes +, vs. ~16s for POWER in the same
Digging into this, I find that a nova soft reboot request is doing
nothing at all on arm64 (no events visible within the qemu guest, and
no reboot is triggered within the guest), and then after some sort of
timeout (~2m), 'nova reboot' falls back to a hard reset of the guest.
Since this is entirely predictable on the arm64 platform (because
there's no implementation of ACPI plumbed through), 'nova reboot' on
arm64 should just skip straight to the hard reboot and save everyone
some clock time.
To manage notifications about this bug go to:
More information about the Ubuntu-openstack-bugs