Open Stack

On Dec 12, 2014, at 1:40 PM, Sean Dague <sean at dague.net> wrote:

> On 12/12/2014 01:05 PM, Maru Newby wrote:
>> 
>> On Dec 11, 2014, at 2:27 PM, Sean Dague <sean at dague.net> wrote:
>> 
>>> On 12/11/2014 04:16 PM, Jay Pipes wrote:
>>>> On 12/11/2014 04:07 PM, Vishvananda Ishaya wrote:
>>>>> On Dec 11, 2014, at 1:04 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>>>>> On 12/11/2014 04:01 PM, Vishvananda Ishaya wrote:
>>>>>>> 
>>>>>>> On Dec 11, 2014, at 8:00 AM, Henry Gessau <gessau at cisco.com> wrote:
>>>>>>> 
>>>>>>>> On Thu, Dec 11, 2014, Mark McClain <mark at mcclain.xyz> wrote:
>>>>>>>>> 
>>>>>>>>>> On Dec 11, 2014, at 8:43 AM, Jay Pipes <jaypipes at gmail.com
>>>>>>>>>> <mailto:jaypipes at gmail.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> I'm generally in favor of making name attributes opaque, utf-8
>>>>>>>>>> strings that
>>>>>>>>>> are entirely user-defined and have no constraints on them. I
>>>>>>>>>> consider the
>>>>>>>>>> name to be just a tag that the user places on some resource. It
>>>>>>>>>> is the
>>>>>>>>>> resource's ID that is unique.
>>>>>>>>>> 
>>>>>>>>>> I do realize that Nova takes a different approach to *some*
>>>>>>>>>> resources,
>>>>>>>>>> including the security group name.
>>>>>>>>>> 
>>>>>>>>>> End of the day, it's probably just a personal preference whether
>>>>>>>>>> names
>>>>>>>>>> should be unique to a tenant/user or not.
>>>>>>>>>> 
>>>>>>>>>> Maru had asked me my opinion on whether names should be unique and I
>>>>>>>>>> answered my personal opinion that no, they should not be, and if
>>>>>>>>>> Neutron
>>>>>>>>>> needed to ensure that there was one and only one default security
>>>>>>>>>> group for
>>>>>>>>>> a tenant, that a way to accomplish such a thing in a race-free
>>>>>>>>>> way, without
>>>>>>>>>> use of SELECT FOR UPDATE, was to use the approach I put into the
>>>>>>>>>> pastebin on
>>>>>>>>>> the review above.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I agree with Jay.  We should not care about how a user names the
>>>>>>>>> resource.
>>>>>>>>> There other ways to prevent this race and Jay’s suggestion is a
>>>>>>>>> good one.
>>>>>>>> 
>>>>>>>> However we should open a bug against Horizon because the user
>>>>>>>> experience there
>>>>>>>> is terrible with duplicate security group names.
>>>>>>> 
>>>>>>> The reason security group names are unique is that the ec2 api
>>>>>>> supports source
>>>>>>> rule specifications by tenant_id (user_id in amazon) and name, so
>>>>>>> not enforcing
>>>>>>> uniqueness means that invocation in the ec2 api will either fail or be
>>>>>>> non-deterministic in some way.
>>>>>> 
>>>>>> So we should couple our API evolution to EC2 API then?
>>>>>> 
>>>>>> -jay
>>>>> 
>>>>> No I was just pointing out the historical reason for uniqueness, and
>>>>> hopefully
>>>>> encouraging someone to find the best behavior for the ec2 api if we
>>>>> are going
>>>>> to keep the incompatibility there. Also I personally feel the ux is
>>>>> better
>>>>> with unique names, but it is only a slight preference.
>>>> 
>>>> Sorry for snapping, you made a fair point.
>>> 
>>> Yeh, honestly, I agree with Vish. I do feel that the UX of that
>>> constraint is useful. Otherwise you get into having to show people UUIDs
>>> in a lot more places. While those are good for consistency, they are
>>> kind of terrible to show to people.
>> 
>> 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?
> 
> Maybe the other ones are the broken ones?
> 
> Honestly, any sanely usable system makes names unique inside a
> container. Like files in a directory. In this case the tenant is the
> container, which makes sense.
> 
> It is one of many places that OpenStack is not consistent. But I'd
> rather make things consistent and more usable than consistent and less.

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.


Maru