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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
