Open Stack

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.

-jay