[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