Open Stack

On 07/07/2014 02:29 PM, Joe Gordon wrote:
> On Jul 7, 2014 3:47 PM, Chris Friesen wrote:
>  > On 07/07/2014 12:35 PM, Day, Phil wrote:

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

Maybe I'm misunderstanding Phil's suggestion, but the phrase

'...group hints passed by name will fail if there is an existing group 
with a policy that isn’t “legacy”...'

sounds like he is *only* supporting specifying group by name for 
"legacy" policy.  That is what I'm objecting against...I want to be able 
to specify a group by name for all scheduling policies.

I'm perfectly happy to have a command fail with a "server group name is 
ambiguous" error if the name matches more than one group in the user's 
namespace.

Chris