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

Ivar Lazzaro ivarlazzaro at gmail.com
Fri Dec 12 18:25:05 UTC 2014

In general, I agree with Jay about the opaqueness of the names. I see
however good reasons for having user-defined unique attributes (see
 Clint's point about idempotency).
A middle ground here could be granting to the users the ability to specify
the resource ID.
A similar proposal was made some time ago by Eugene [0]


On Thu, Dec 11, 2014 at 6:59 AM, Mark McClain <mark at mcclain.xyz> wrote:
> On Dec 11, 2014, at 8:43 AM, Jay Pipes <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.
> mark
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141212/b059f542/attachment.html>

More information about the OpenStack-dev mailing list