Open Stack

On Jul 7, 2014 3:47 PM, "Chris Friesen" <chris.friesen at windriver.com> wrote:
>
> On 07/07/2014 12:35 PM, Day, Phil wrote:
>>
>> Hi Folks,
>>
>> I noticed a couple of changes that have just merged to allow the server
>> group hints to be specified by name (some legacy behavior around
>> automatically creating groups).
>>
>> https://review.openstack.org/#/c/83589/
>>
>> https://review.openstack.org/#/c/86582/
>>
>> But group names aren’t constrained to be unique, and the method called
>> to get the group instance_group_obj.InstanceGroup.get_by_name() will
>> just return the first group I finds with that name (which could be
>> either the legacy group or some new group, in which case the behavior is
>> going to be different from the legacy behavior I think ?
>>
>> I’m thinking that there may need to be some additional logic here, so
>> that group hints passed by name will fail if there is an existing group
>> with a policy that isn’t “legacy” – and equally perhaps group creation
>> needs to fail if a legacy groups exists with the same name ?
>
>
> Sorry, forgot to put this in my previous message.  I've been advocating
the ability to use names instead of UUIDs for server groups pretty much
since I saw them last year.
>
> I'd like to just enforce that server group names must be unique within a
tenant, and then allow names to be used anywhere we currently have UUIDs
(the way we currently do for instances).  If there is ambiguity (like from
admin doing an operation where there are multiple groups with the same name
in different tenants) then we can have it fail with an appropriate error
message.

The question here is not just about server group names, but all names.
Having one name be unique and not another (instance names), is a recipe for
a poor user experience. Unless there is a strong reason why our current
model is bad ( non unique names), I don't think this type of change is
worth the impact on users.

>
>
> Chris
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/46c1f601/attachment.html>