Bug 1310174 - consume_from_instance is not synchronized
consume_from_instance is not synchronized
Status: ASSIGNED
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
urgent Severity urgent
: ---
: ---
Assigned To: Sylvain Bauza
awaugama
: Reopened, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-19 11:29 EST by Sylvain Bauza
Modified: 2017-11-10 21:53 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-19 08:44:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 259892 None None None 2016-02-19 11:29 EST

  None (edit)
Description Sylvain Bauza 2016-02-19 11:29:23 EST
Nova-scheduler doesn't provide a locking mechanism for ensuring that two greenthreads are synchronized when calling the method responsible for consuming resources.

The BP https://blueprints.launchpad.net/nova/+spec/host-state-level-locking proposes two patches that fix that.
Comment 2 Perry Myers 2016-02-19 11:48:00 EST
The BP is for Mitaka, this bug is to track a potential backport of this BP in part to OSP8/Liberty to resolve (at least partially) the race condition that exists between Ironic and Nova when using TripleO.

Investigation needs to be done by sbauza to determine if the patches slated to land in Mitaka are enough to be worth backporting, given any invasiveness.

Workaround investigation will be done via bug 1310178 in case this is not successful.
Comment 8 Stephen Gordon 2017-04-19 08:57:04 EDT
Sylvain what is the current status of this from an upstream perspective?
Comment 9 Sylvain Bauza 2017-04-21 04:40:24 EDT
Stephen, the proposer seems to have moved and is no longer focusing on Nova (but still working on Ceph). Anyway, the missing bits (using Claims object in the scheduler like the compute ResourceTracker does) are something not really needed now that we have the Placement API.

Instead, I'm trying to provide a new feature for having the scheduler (or the conductor) doing claims by posting allocations to the Placement API, which would superseding the above blueprint https://review.openstack.org/#/c/437424/

The "scheduler claims" BP is still needing some discussion by the Boston Forum https://www.openstack.org/summit/boston-2017/summit-schedule/events/18723/moving-resource-claims-from-nova-compute-to-nova-scheduler so we could implement it by Queens.

Note You need to log in before you can comment on or make changes to this bug.