Bug 1310174

Summary: consume_from_instance is not synchronized
Product: Red Hat OpenStack Reporter: Sylvain Bauza <sbauza>
Component: openstack-novaAssignee: Sylvain Bauza <sbauza>
Status: CLOSED WONTFIX QA Contact: awaugama
Severity: urgent Docs Contact:
Priority: urgent    
Version: 8.0 (Liberty)CC: berrange, dasmith, eglynn, kchamart, lyarwood, mburns, sbauza, scorcora, sferdjao, sgordon, srevivo, tvignaud, vromanso
Target Milestone: ---Keywords: Reopened, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-01-17 15:54:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sylvain Bauza 2016-02-19 16:29:23 UTC
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 16:48:00 UTC
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 12:57:04 UTC
Sylvain what is the current status of this from an upstream perspective?

Comment 9 Sylvain Bauza 2017-04-21 08:40:24 UTC
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.

Comment 11 Sylvain Bauza 2018-01-17 15:54:10 UTC
Now that we have the scheduler making allocation to the Placement API, that specific BZ is no longer needed. Closing it.