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

Jay Pipes jaypipes at gmail.com
Thu Dec 11 13:43:46 UTC 2014


On 12/11/2014 07:22 AM, Anna Kamyshnikova wrote:
> Hello everyone!
>
> In neutron there is a rather old bug [1] about adding uniqueness for
> security group name and tenant id. I found this idea reasonable and
> started working on fix for this bug [2]. I think it is good to add a
> uniqueconstraint because:
>
> 1) In nova there is such constraint for security groups
> https://github.com/openstack/nova/blob/stable/juno/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1155-L1157.
> So I think that it is rather disruptive that it is impossible to create
> security group with the same name in nova, but possible in neutron.
> 2) Users get confused having security groups with the same name.
>
> In comment for proposed change Assaf Muller and Maru Newby object for
> such solution and suggested another option, so I think we need more eyes
> on this change.
>
> I would like to ask you to share your thoughts on this topic.
> [1] - https://bugs.launchpad.net/neutron/+bug/1194579
> [2] - https://review.openstack.org/135006

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.

Best,
-jay



More information about the OpenStack-dev mailing list