yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem.os@xxxxxxxxx>]

The problem is that the periodic doesn't have a token, and
[glance]/api_servers isn't configured, so when the notification code is
trying to build a payload, it's trying to get the image API endpoint URL
to build a link to the image for the notification. Getting the endpoint
URL without a token fails.

This is the code that matters:

https://github.com/openstack/nova/blob/7833ada4fd8e42a773cb6849449708fcb20cbc0c/nova/notifications/base.py#L397

https://github.com/openstack/nova/blob/7833ada4fd8e42a773cb6849449708fcb20cbc0c/nova/image/api.py#L65

https://github.com/openstack/nova/blob/7833ada4fd8e42a773cb6849449708fcb20cbc0c/nova/image/glance.py#L120

If [glance]/api_servers is configured, then we don't go through
keystoneauth1 to get the service catalog from keystone.

So options seem to be:

1. Add the ability to specify an admin or service user credentials in
nova.conf for the [glance] section which we can use during periodics.
This is a bit heavy weight when we've never needed it before.

2. Handle the EndpointNotFound error when building the notification
payload and just set image_ref_url to the image id. Yes this is
technically a change in the payload, but it's better than breaking
everything. Long-term, the versioned notification payload could drop
image_ref_url and just pass the image id, which is probably more useful
anyway since the consumer might not be able to even reach the URL that's
in the payload. We can't change the legacy notification payload, but we
can eventually deprecate that in favor of the versioned notifications.

** Also affects: nova/queens
   Importance: Undecided
       Status: New

** Changed in: nova/queens
       Status: New => Triaged

** Changed in: nova/queens
   Importance: Undecided => Medium

-- 
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):
  Triaged
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