Firewall rules from nova-compute are not refreshed after host reboot

Bug #985162 reported by Tomasz Paszkowski
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Medium
Dan Prince
Essex
Fix Released
Undecided
Unassigned
nova (Ubuntu)
Fix Released
Undecided
Unassigned
Precise
Fix Released
Undecided
Unassigned

Bug Description

When whole host is rebooted and FLAGS.resume_guests_state_on_host_boot is present nova-compute is rebooting all instances. This works perfectly but unfortunately firewall rules are not created. Solution to this problem is to change reboot type to hard which will ensure firewall rules.

line #247, compute/manager.py:

-self.reboot_instance(context, instance['uuid'])
+self.reboot_instance(context, instance['uuid'],'HARD')

Related branches

Revision history for this message
Tomasz Paszkowski (ss7pro) wrote :

any progress on this issue ?

Revision history for this message
Andrew Clay Shafer (littleidea) wrote :

I peeked at the code now. Right now this is an unassigned issue, so I wouldn't expect progress until it is assigned to someone.

I think the fix should probably be to make sure a soft reboot sets up the right networking instead of doing hard reboots, but I would defer that decision to someone on nova core.

Revision history for this message
Christoph Dwertmann (cdwertmann) wrote :

I can confirm this bug is present in Openstack Essex (packages from Ubuntu 12.04)

Dan Prince (dan-prince)
Changed in nova:
assignee: nobody → Dan Prince (dan-prince)
status: New → In Progress
Revision history for this message
Dan Prince (dan-prince) wrote :

Looking a bit at the code across hypervisors it appears that a virt driver 'reboot' can have quite different implementations.

Switching to a hard reboot will definitely fix this issue on libvirt. I took a look at the XenServer code as well it it looks like both hard and soft reboots would leave firewall rules unconfigured... so I'm not sure this is a good all around solution. I'm actually not even sure the XenServer code would work in this case to resume an instance...

I'm actually leaning towards implementing a proper virt driver method for this so that each hypervisor can cleanly implement the correct solution.

Changed in nova:
importance: Undecided → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/8035
Committed: http://github.com/openstack/nova/commit/6548c509f1780a7168f26de6f2045ec7d5768520
Submitter: Jenkins
Branch: master

commit 6548c509f1780a7168f26de6f2045ec7d5768520
Author: Dan Prince <email address hidden>
Date: Fri Jun 1 10:34:11 2012 -0400

    Implements resume_state_on_host_boot for libvirt.

    Adds a new virt driver function to help resume guest states
    on host boot. This fixes a couple issue with using a reboot
    (like we did previously):

     * Using reboot would clear some task states (VERIFY_RESIZE for example)
     * Provides a mechanism for hypervisor specific guest restarts.
       Reboot would not have worked for XenServer for example...
     * Updates libvirt to use a hard reboot (instead of soft)

    Fixes LP Bug #985162.

    Change-Id: Iaf5aad75ec9b91f44710a18ddaf3a93378573a62

Changed in nova:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/essex)

Fix proposed to branch: stable/essex
Review: https://review.openstack.org/8423

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (stable/essex)

Reviewed: https://review.openstack.org/8423
Committed: http://github.com/openstack/nova/commit/27133eed735c6d5c8015b1bc40d89b55df3a984b
Submitter: Jenkins
Branch: stable/essex

commit 27133eed735c6d5c8015b1bc40d89b55df3a984b
Author: Dan Prince <email address hidden>
Date: Fri Jun 1 10:34:11 2012 -0400

    Implements resume_state_on_host_boot for libvirt.

    Adds a new virt driver function to help resume guest states
    on host boot. This fixes a couple issue with using a reboot
    (like we did previously):

     * Using reboot would clear some task states (VERIFY_RESIZE for example)
     * Provides a mechanism for hypervisor specific guest restarts.
       Reboot would not have worked for XenServer for example...
     * Updates libvirt to use a hard reboot (instead of soft)

    Fixes LP Bug #985162.

    Change-Id: Iaf5aad75ec9b91f44710a18ddaf3a93378573a62
    (cherry picked from commit 6548c509f1780a7168f26de6f2045ec7d5768520)

Thierry Carrez (ttx)
Changed in nova:
milestone: none → folsom-2
status: Fix Committed → Fix Released
Dave Walker (davewalker)
Changed in nova (Ubuntu):
status: New → Fix Released
Changed in nova (Ubuntu Precise):
status: New → Confirmed
Revision history for this message
Adam Gandelman (gandelman-a) wrote : Verification report.

Please find the attached test log from the Ubuntu Server Team's CI infrastructure. As part of the verification process for this bug, Nova has been deployed and configured across multiple nodes using precise-proposed as an installation source. After successful bring-up and configuration of the cluster, a number of exercises and smoke tests have be invoked to ensure the updated package did not introduce any regressions. A number of test iterations were carried out to catch any possible transient errors.

Please Note the list of installed packages at the top and bottom of the report.

For records of upstream test coverage of this update, please see the Jenkins links in the comments of the relevant upstream code-review(s):

Trunk review: https://review.openstack.org/8035
Stable review: https://review.openstack.org/8423

As per the provisional Micro Release Exception granted to this package by the Technical Board, we hope this contributes toward verification of this update.

Revision history for this message
Adam Gandelman (gandelman-a) wrote :

Test coverage log.

tags: added: verification-done
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.4 KiB)

This bug was fixed in the package nova - 2012.1.3+stable-20120827-4d2a4afe-0ubuntu1

---------------
nova (2012.1.3+stable-20120827-4d2a4afe-0ubuntu1) precise-proposed; urgency=low

  * New upstream snapshot, fixes FTBFS in -proposed. (LP: #1041120)
  * Resynchronize with stable/essex (4d2a4afe):
    - [5d63601] Inappropriate exception handling on kvm live/block migration
      (LP: #917615)
    - [ae280ca] Deleted floating ips can cause instance delete to fail
      (LP: #1038266)

nova (2012.1.3+stable-20120824-86fb7362-0ubuntu1) precise-proposed; urgency=low

  * New upstream snapshot. (LP: #1041120)
  * Dropped, superseded by new snapshot:
    - debian/patches/CVE-2012-3447.patch: [d9577ce]
    - debian/patches/CVE-2012-3371.patch: [25f5bd3]
    - debian/patches/CVE-2012-3360+3361.patch: [b0feaff]
  * Resynchronize with stable/essex (86fb7362):
    - [86fb736] Libvirt driver reports incorrect error when volume-detach fails
      (LP: #1029463)
    - [272b98d] nova delete lxc-instance umounts the wrong rootfs (LP: #971621)
    - [09217ab] Block storage connections are NOT restored on system reboot
      (LP: #1036902)
    - [d9577ce] CVE-2012-3361 not fully addressed (LP: #1031311)
    - [e8ef050] pycrypto is unused and the existing code is potentially insecure
      to use (LP: #1033178)
    - [3b4ac31] cannot umount guestfs (LP: #1013689)
    - [f8255f3] qpid_heartbeat setting in ineffective (LP: #1030430)
    - [413c641] Deallocation of fixed IP occurs before security group refresh
      leading to potential security issue in error / race conditions
      (LP: #1021352)
    - [219c5ca] Race condition in network/deallocate_for_instance() leads to
      security issue (LP: #1021340)
    - [f2bc403] cleanup_file_locks does not remove stale sentinel files
      (LP: #1018586)
    - [4c7d671] Deleting Flavor currently in use by instance creates error
      (LP: #994935)
    - [7e88e39] nova testsuite errors on newer versions of python-boto (e.g.
      2.5.2) (LP: #1027984)
    - [80d3026] NoMoreFloatingIps: Zero floating ips available after repeatedly
      creating and destroying instances over time (LP: #1017418)
    - [4d74631] Launching with source groups under load produces lazy load error
      (LP: #1018721)
    - [08e5128] API 'v1.1/{tenant_id}/os-hosts' does not return a list of hosts
      (LP: #1014925)
    - [801b94a] Restarting nova-compute removes ip packet filters (LP: #1027105)
    - [f6d1f55] instance live migration should create virtual_size disk image
      (LP: #977007)
    - [4b89b4f] [nova][volumes] Exceeding volumes, gigabytes and floating_ips
      quotas returns general uninformative HTTP 500 error (LP: #1021373)
    - [6e873bc] [nova][volumes] Exceeding volumes, gigabytes and floating_ips
      quotas returns general uninformative HTTP 500 error (LP: #1021373)
    - [7b215ed] Use default qemu-img cluster size in libvirt connection driver
    - [d3a87a2] Listing flavors with marker set returns 400 (LP: #956096)
    - [cf6a85a] nova-rootwrap hardcodes paths instead of using
      /sbin:/usr/sbin:/usr/bin:/bin (LP: #1013147)
    - [2efc87c] affinity filters don't work if scheduler_hints is None
      (LP: #1007573)
  ...

Read more...

Changed in nova (Ubuntu Precise):
status: Confirmed → Fix Released
Revision history for this message
Clint Byrum (clint-fewbar) wrote : Update Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Thierry Carrez (ttx)
Changed in nova:
milestone: folsom-2 → 2012.2
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.