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

Jay Pipes jaypipes at gmail.com
Thu Dec 11 21:04:05 UTC 2014


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



More information about the OpenStack-dev mailing list