Open Stack

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...

Best,
-jay