<div dir="ltr">I think the point made is that the behaviour is currently inconsistent and not user friendly.<div>Regardless of that, I would like to point that technically this kind of change is backward incompatible and so it should not be simply approved by popular acclamation.</div><div><br></div><div>I will seek input from the API WG in the next meeting.</div><div><br></div><div>Salvatore</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 December 2014 at 20:39, Maru Newby <span dir="ltr"><<a href="mailto:marun@redhat.com" target="_blank">marun@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Dec 12, 2014, at 1:40 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
> On 12/12/2014 01:05 PM, Maru Newby wrote:<br>
>><br>
>> On Dec 11, 2014, at 2:27 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
>><br>
>>> On 12/11/2014 04:16 PM, Jay Pipes wrote:<br>
>>>> On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:<br>
>>>>> On Dec 11, 2014, at 1:04 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>>>>>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:<br>
>>>>>>><br>
>>>>>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau <<a href="mailto:gessau@cisco.com">gessau@cisco.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>>> On Thu, Dec 11, 2014, Mark McClain <mark@mcclain.xyz> wrote:<br>
>>>>>>>>><br>
>>>>>>>>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>
>>>>>>>>>> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>> wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>> I'm generally in favor of making name attributes opaque, utf-8<br>
>>>>>>>>>> strings that<br>
>>>>>>>>>> are entirely user-defined and have no constraints on them. I<br>
>>>>>>>>>> consider the<br>
>>>>>>>>>> name to be just a tag that the user places on some resource. It<br>
>>>>>>>>>> is the<br>
>>>>>>>>>> resource's ID that is unique.<br>
>>>>>>>>>><br>
>>>>>>>>>> I do realize that Nova takes a different approach to *some*<br>
>>>>>>>>>> resources,<br>
>>>>>>>>>> including the security group name.<br>
>>>>>>>>>><br>
>>>>>>>>>> End of the day, it's probably just a personal preference whether<br>
>>>>>>>>>> names<br>
>>>>>>>>>> should be unique to a tenant/user or not.<br>
>>>>>>>>>><br>
>>>>>>>>>> Maru had asked me my opinion on whether names should be unique and I<br>
>>>>>>>>>> answered my personal opinion that no, they should not be, and if<br>
>>>>>>>>>> Neutron<br>
>>>>>>>>>> needed to ensure that there was one and only one default security<br>
>>>>>>>>>> group for<br>
>>>>>>>>>> a tenant, that a way to accomplish such a thing in a race-free<br>
>>>>>>>>>> way, without<br>
>>>>>>>>>> use of SELECT FOR UPDATE, was to use the approach I put into the<br>
>>>>>>>>>> pastebin on<br>
>>>>>>>>>> the review above.<br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> I agree with Jay.  We should not care about how a user names the<br>
>>>>>>>>> resource.<br>
>>>>>>>>> There other ways to prevent this race and Jay’s suggestion is a<br>
>>>>>>>>> good one.<br>
>>>>>>>><br>
>>>>>>>> However we should open a bug against Horizon because the user<br>
>>>>>>>> experience there<br>
>>>>>>>> is terrible with duplicate security group names.<br>
>>>>>>><br>
>>>>>>> The reason security group names are unique is that the ec2 api<br>
>>>>>>> supports source<br>
>>>>>>> rule specifications by tenant_id (user_id in amazon) and name, so<br>
>>>>>>> not enforcing<br>
>>>>>>> uniqueness means that invocation in the ec2 api will either fail or be<br>
>>>>>>> non-deterministic in some way.<br>
>>>>>><br>
>>>>>> So we should couple our API evolution to EC2 API then?<br>
>>>>>><br>
>>>>>> -jay<br>
>>>>><br>
>>>>> No I was just pointing out the historical reason for uniqueness, and<br>
>>>>> hopefully<br>
>>>>> encouraging someone to find the best behavior for the ec2 api if we<br>
>>>>> are going<br>
>>>>> to keep the incompatibility there. Also I personally feel the ux is<br>
>>>>> better<br>
>>>>> with unique names, but it is only a slight preference.<br>
>>>><br>
>>>> Sorry for snapping, you made a fair point.<br>
>>><br>
>>> Yeh, honestly, I agree with Vish. I do feel that the UX of that<br>
>>> constraint is useful. Otherwise you get into having to show people UUIDs<br>
>>> in a lot more places. While those are good for consistency, they are<br>
>>> kind of terrible to show to people.<br>
>><br>
>> While there is a good case for the UX of unique names - it also makes orchestration via tools like puppet a heck of a lot simpler - the fact is that most OpenStack resources do not require unique names.  That being the case, why would we want security groups to deviate from this convention?<br>
><br>
> Maybe the other ones are the broken ones?<br>
><br>
> Honestly, any sanely usable system makes names unique inside a<br>
> container. Like files in a directory. In this case the tenant is the<br>
> container, which makes sense.<br>
><br>
> It is one of many places that OpenStack is not consistent. But I'd<br>
> rather make things consistent and more usable than consistent and less.<br>
<br>
</div></div>You might prefer less consistency for the sake of usability, but for me, consistency is a large enough factor in usability that allowing seemingly arbitrary deviation doesn’t seem like a huge win.  Regardless, I’d like to see us came to decisions on API usability on an OpenStack-wide basis, so the API working group is probably where this discussion should continue.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Maru<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div>