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

Vishvananda Ishaya vishvananda at gmail.com
Thu Dec 11 21:07:52 UTC 2014


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.

Vish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141211/eb9a9d38/attachment.pgp>


More information about the OpenStack-dev mailing list