Open Stack

On 2/20/15 9:06 AM, Mike Dorman wrote:
> I can report that we do use this option (‘global' setting.)  We have to
> enforce name uniqueness for instances’ integration with some external
> systems (namely AD and Spacewalk) which require unique naming.
>
> However, we also do some external name validation which I think
> effectively enforces uniqueness as well.  So if this were deprecated, I
> don’t know if it would directly affect us for our specific situation.
>
> Other operators, anyone else using osapi_compute_unique_server_name_scope?
I use it!  And, in fact, added it in the first place :(

I have no real recall of what we concluded when originally discussing 
the associated race.  The feature is useful to me and I'd love it if it 
could be moved into the db to fix the race, but I concede that it's a 
pretty big can o' worms, so if no one else cries out in pain I can live 
with it being deprecated.

-Andrew


>
> Mike
>
>
>
>
>
> On 2/19/15, 3:18 AM, "Matthew Booth" <mbooth at redhat.com> 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.
>>
>> Thanks,
>>
>> Matt
>>
>> [1] Which has prompted me to get the test_db_api tests running on MySQL.
>> See this series if you're interested:
>> https://review.openstack.org/#/c/156299/
>>
>> [2] For specifics, see my ramblings here:
>> https://review.openstack.org/#/c/141115/7/nova/db/sqlalchemy/api.py,cm
>> line 2547
>> -- 
>> 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
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev