[openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

Sean Dague sean at dague.net
Thu Dec 11 22:27:00 UTC 2014

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.


Sean Dague

More information about the OpenStack-dev mailing list