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

Clint Byrum clint at fewbar.com
Fri Dec 12 00:23:53 UTC 2014


Excerpts from Jay Pipes's message of 2014-12-11 05:43:46 -0800:
> 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.
> 

The problem with this approach is that it requires the user to have an
external mechanism to achieve idempotency. By allowing an opaque string
that the user submits to you to be guaranteed to be unique, you allow
the user to write "dumber" code around creation in an unreliable
fashion. So instead of


while True:
  try:
    item = clientlib.find(name='foo')[0]
    break
  except NotFound:
    try:
      item = clientlib.create(name='foo')
      break
    except UniqueConflict:
      item = clientlib.find(name='foo')[0]
      break

You can keep retrying forever because you know only one thing with that
name will ever exist.

Without unique names, you have to write weird stuff like this to do a
retry.

while len(clientlib.find(name='foo')) < 1:
  try:
    item = clientlib.create(name='foo')
    list = clientlib.searchfor(name='foo')
    for found_item in list:
      if found_item.id != item.id:
        clientlib.delete(found_item.id)

Name can certainly remain not-unique and free-form, but don't discount
the value of a unique value that the user specifies.



More information about the OpenStack-dev mailing list