yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem@xxxxxxxxxx>]

Public bug reported:

Debugging a failure I see this several times in the logs:

http://logs.openstack.org/07/263207/1/check/gate-manila-tempest-dsvm-
neutron-no-share-servers-
multibackend/6717bb8/logs/screen-n-cpu.txt.gz#_2016-01-04_11_17_18_679

2016-01-04 11:17:18.679 DEBUG nova.objects.instance [req-
576413dd-8271-4110-995a-e6b828dc3035 nova service] Lazy-loading `flavor'
on Instance uuid b4e9b1a0-77c7-4bde-9413-e14dfe7e3601 obj_load_attr
/opt/stack/new/nova/nova/objects/instance.py:843

This is happening when attaching a volume to the instance and it's
trying to determine the device to use for the mountpoint.

The instance is retrieved in the API and by default it doesn't include
the flavor attribute (which is a join on another table).

This code is lazy-loading the flavor attribute on the instance, which
with remote conductor is a round trip over rpc to conductor to get the
flavor from the database and store it back on the instance:

https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L522

And this is only used if the block_device_info doesn't have any swap
information in it:

https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L579

So we should avoid the round-trip to conductor and not lazy-load the
flavor if we can, which means only getting it if that first condition
fails (no swap info in the block_device_info).

** Affects: nova
     Importance: Low
     Assignee: Matt Riedemann (mriedem)
         Status: Triaged


** Tags: libvirt volumes

** Changed in: nova
   Importance: Undecided => Low

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

-- 
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/1530952

Title:
  libvirt: should only lazy-load flavor from instance in
  get_disk_mapping if necessary

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  Debugging a failure I see this several times in the logs:

  http://logs.openstack.org/07/263207/1/check/gate-manila-tempest-dsvm-
  neutron-no-share-servers-
  multibackend/6717bb8/logs/screen-n-cpu.txt.gz#_2016-01-04_11_17_18_679

  2016-01-04 11:17:18.679 DEBUG nova.objects.instance [req-
  576413dd-8271-4110-995a-e6b828dc3035 nova service] Lazy-loading
  `flavor' on Instance uuid b4e9b1a0-77c7-4bde-9413-e14dfe7e3601
  obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:843

  This is happening when attaching a volume to the instance and it's
  trying to determine the device to use for the mountpoint.

  The instance is retrieved in the API and by default it doesn't include
  the flavor attribute (which is a join on another table).

  This code is lazy-loading the flavor attribute on the instance, which
  with remote conductor is a round trip over rpc to conductor to get the
  flavor from the database and store it back on the instance:

  https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L522

  And this is only used if the block_device_info doesn't have any swap
  information in it:

  https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L579

  So we should avoid the round-trip to conductor and not lazy-load the
  flavor if we can, which means only getting it if that first condition
  fails (no swap info in the block_device_info).

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