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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev