[openstack-dev] [Nova] Grant FFE to "Host-state level locking" BP
ndipanov at redhat.com
Fri Mar 4 14:34:18 UTC 2016
On 03/04/2016 02:06 PM, John Garbutt wrote:
> As on IRC, I don't think this should get an FFE this cycle.
> On 4 March 2016 at 10:56, Nikola Đipanov <ndipanov at redhat.com> wrote:
>> The actual BP that links to the approved spec is here:  and 2
>> outstanding patches are .
>> Apart from the usual empathy-inspired reasons to allow this (code's been
>> up for a while, yet only had real review on the last day etc.) which are
>> not related to the technical merit of the work, there is also the fact
>> that two initial patches that add locking around updates of the
>> in-memory host map ( and ) have already been merged.
>> They add the overhead of locking to the scheduler, but without the final
>> work they don't provide any benefits (races will not be detected,
>> without ).
> We could land a patch to drop the synchronized decorators, but it
> seemed like it might still help (the possibly theoretical issue?) of
> two greenlets competing decrementing the same resource counts.
>> I don't have any numbers on this but the result is likely that we made
>> things worse, for the sake of adhering to random and made-up dates.
> For details on the reasons behind our process, please see:
>> this in mind I think it only makes sense to do our best to merge the 2
>> outstanding patches.
> Looking at the feature freeze exception criteria:
> The code is not ready to merge right now, so its hard to asses the
> risk of merging it, and hard to asses how long it will take to merge.
> It seems medium-ish risk, given the existing patches.
> We have had 2 FFEs, just for things that were +Wed but merged when we
> cut mitaka-3. They are all merged now.
> Time is much tighter this cycle than usual. We also seem to have less
> reviewers doing reviews than normal for this point in the cycle, and a
> much bigger backlog of bug fixes to review. We only have about 7 more
> working days between now and tagging RC1, at which point master opens
> for Newton, and these patches are free to merge again.
> While this is useful, its not a regression. It would help us detect
> races in the scheduler sooner. It does not feel release critical.
Thanks for the response John,
If we take "release critical" to mean "Nova not able to start VMs if we
don't have this", then no - it's not release critical.
But it does mean that people consuming releases will not get to use this
and consequently find and report bugs for another 6 months.
On a more personal note - this is the second thing that I was involved
with this cycle that got accepted, only to get half merged over a random
deadline. The other one being , which was just integration work that
would make a lot of other work that went in this cycle (in both Nova and
Neutron) usable. Again - the result is, we have the code in tree, but no
one can use it and test it.
Even if I try to keep my personal feelings out of this - I still feel
that this is a massive waste we are happy to accept for practically 0 gain.
More information about the OpenStack-dev