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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
