yahoo-eng-team team mailing list archive

[OpenStack Infra <1753550@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/554703
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6482165bb1f44f5c98d9361153d737c22c92112d
Submitter: Zuul
Branch:    master

commit 6482165bb1f44f5c98d9361153d737c22c92112d
Author: Matt Riedemann <mriedem.os@xxxxxxxxx>
Date:   Tue Mar 20 17:15:42 2018 -0400

    Handle EndpointNotFound when building image_ref_url in notifications
    
    Change I4e755b9c66ec8bc3af0393e81cffd91c56064717 made the
    [glance]/api_servers option optional. If not set, we attempt
    to get the image service endpoint via keystoneauth adapter and
    the service catalog via the request context.
    
    Periodic tasks run without an actual token so there is no way
    to get the service catalog and the KSA adapter code to get the
    endpoint raises EndpointNotFound when trying to build the
    "image_ref_url" entry in the legacy instance notification payload.
    
    This change simply handles the EndpointNotFound and sets the
    image_ref_url to the instance.image_ref, which for non-volume-backed
    instances is the image id (for volume-backed instances it's an empty
    string).
    
    This doesn't affect versioned notifications since those don't use the
    "image_ref_url" entry in the payload that is created, they just have
    an "image_uuid" entry in the versioned notification payload which is
    populated via instance.image_ref.
    
    An upgrade impact release note is added in the case that some consuming
    service is actually relying on that legacy notification field being
    a URL and parsing it as such. The thinking here, however, is this is
    better than not sending the field at all, or setting it to None.
    
    Long-term this code all gets replaced with versioned notifications.
    
    Change-Id: Ie23a9c922776b028da0720c939846cba233ac472
    Closes-Bug: #1753550


** Changed in: nova
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1753550

Title:
  Status does not update to "Shutoff" when instance shuts down itself

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  Triaged

Bug description:
  For instances that shut down themselves, the status remains Active,
  even though the power state updates to Shutdown. If however the
  shutdown signal is sent via openstack it does change the status to
  "SHUTOFF".

  After creating an instance, the states are:
  +------------------------+---------+
  | Field                  | Value   |
  +------------------------+---------+
  | OS-EXT-STS:power_state | Running |
  | OS-EXT-STS:task_state  | None    |
  | OS-EXT-STS:vm_state    | active  |
  | status                 | ACTIVE  |
  +------------------------+---------+

  Using openstack server stop results in:
  +------------------------+----------+
  | Field                  | Value    |
  +------------------------+----------+
  | OS-EXT-STS:power_state | Shutdown |
  | OS-EXT-STS:task_state  | None     |
  | OS-EXT-STS:vm_state    | stopped  |
  | status                 | SHUTOFF  |
  +------------------------+----------+

  However logging into the instance and using the poweroff command results in:
  +------------------------+----------+
  | Field                  | Value    |
  +------------------------+----------+
  | OS-EXT-STS:power_state | Shutdown |
  | OS-EXT-STS:task_state  | None     |
  | OS-EXT-STS:vm_state    | active   |
  | status                 | ACTIVE   |
  +------------------------+----------+

  This results in being unable to use the openstack server start command
  on it fails and returns:

  # openstack server start test_shutdown
  Cannot 'start' instance 8881bebb-efbd-45e6-a052-7d23b9b63222 while it is in vm_state active (HTTP 409) (Request-ID: req-e473415d-d6e0-4342-b1f6-267efa934dc0)

  despite the virtual machine being powered off. You can work around
  this by running openstack server stop, and then openstack server
  start.

  This is also an issue for external applications that check the status
  (and how I noticed it to begin with).

  This on devstack with commit id:
  5d2add74534719c5670b29152964a60e8f23b42b

  Not sure if the following is useful, but
  - Using hypervisor libvirt+qemu/kvm:
  # virsh version
  Compiled against library: libvirt 3.2.0
  Using library: libvirt 3.2.0
  Using API: QEMU 3.2.0
  Running hypervisor: QEMU 2.9.0
  - Using ephemeral storage with ex4
  - Neutron with OpenVSwitch

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1753550/+subscriptions