Open Stack

On 19/02/15 18:57, Jay Pipes wrote:
> On 02/19/2015 05:18 AM, Matthew Booth wrote:
>> Nova contains a config variable osapi_compute_unique_server_name_scope.
>> Its help text describes it pretty well:
>>
>> When set, compute API will consider duplicate hostnames invalid within
>> the specified scope, regardless of case. Should be empty, "project" or
>> "global".
>>
>> So, by default hostnames are not unique, but depending on this setting
>> they could be unique either globally or in the scope of a project.
>>
>> Ideally a unique constraint would be enforced by the database but,
>> presumably because this is a config variable, that isn't the case here.
>> Instead it is enforced in code, but the code which does this predictably
>> races. My first attempt to fix this using the obvious SQL solution
>> appeared to work, but actually fails in MySQL as it doesn't support that
>> query structure[1][2]. SQLite and PostgreSQL do support it, but they
>> don't support the query structure which MySQL supports. Note that this
>> isn't just a syntactic thing. It looks like it's still possible to do
>> this if we compound the workaround with a second workaround, but I'm
>> starting to wonder if we'd be better fixing the design.
>>
>> First off, do we need this config variable? Is anybody actually using
>> it? I suspect the answer's going to be yes, but it would be extremely
>> convenient if it's not.
>>
>> Assuming this configurability is required, is there any way we can
>> instead use it to control a unique constraint in the db at service
>> startup? This would be something akin to a db migration. How do we
>> manage those?
>>
>> Related to the above, I'm not 100% clear on which services run this
>> code. Is it possible for different services to have a different
>> configuration of this variable, and does that make sense? If so, that
>> would preclude a unique constraint in the db.
> 
> Is there a bug that you are attempting to fix here? If not, I'd suggest
> just leaving this code as it is...

The bug is the race. If a user sets
osapi_compute_unique_server_name_scope they're presumably expecting the
associating uniqueness guarantees, but we're not providing them.

John suggested I deprecate it and see who complains:

https://review.openstack.org/157731

In the mean time, I'm starting to think the most prudent course of
action would be to not fix the race: it's not the most important race in
that function, it's been broken for a long time, and I suspect few
people are using it. We could document that it's broken... In fact, I
might add that to the deprecation notice.

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490