Open Stack

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

I think in general we've moved away from using names at the API layer and pushed name to UUID translation into the clients for a better command line experience, which seems like the
right thing to do.  The only reason the legacy groups are based on names is because the creation was an implicit side effect of the first call to use the group.  Since we're presumably going
to deprecate support for that at some stage then keeping new API to be UUID based seems the right direction to me.

If we now try to enforce unique names even in the new groups API that would be change that would probably needs its own extension as it’s a break in behavior, so what I'm proposing is
that any group processing based on name in a hint explicitly means a group with that name and a policy of "legacy", so the code would need to change so that when dealing with name
based hints:
- The group is created if there is no existing group with a policy of "legacy"  (at the moment it wouldn't be created if a new group exists of the same name)
- The filter scheduler should only find groups with a policy of "legacy" when looking for them by name

Looking at the current implementation I think this could be done inside the get_by_hint() and get_by_name() methods of the Instance Group Object - does that work for people ?
(It looks to me that these were only introduced in order to support the legacy groups - I'm just not sure if its Ok to embed this "legacy only" behavior inside those calls)

Phil