On 20/02/15 20:15, Andrew Bogott wrote:
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,
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,
On Thu, Feb 19, 2015, Matthew Booth mbo...@redhat.com wrote:
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?
Ignoring if this
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
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
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
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
