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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
