[openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group
rochelle.grober at huawei.com
Fri Dec 12 00:32:26 UTC 2014
First, I agree that it's much friendlier to have unique security group names and not have to use UUIDs since when there is a need for more than a "default", the Tennant admin will want to be able to easily track info related to it, plus in the GUI, if it allows a new one to be created, it should disallow "default", but should allow modification of that SG. Also, the GUI could easily suggest adding a number or letter to the end of the new name if the one suggested by the user is already in use.
So, GUI, logs, and policy issues all rolled into this discussion.
Now to my cause....
Log rationalization! YES! So, I would classify this as a bug in the logging component of Nova. As Mathieu states, this is a known condition, so this should be an ERROR or perhaps WARN that includes which SG name is a duplicate (the NoUniqueMatch statement does this, identifying 'default'), and the "Use an ID to be more specific" as a helpful pointer.
If a bug has not been filed yet, could you file one, with the pointer to the paste file and tag it "log" or "log impact"? And I'd love if you put me on the list of people who should be informed (rockyg).
Thanks for considering the enduser(s) impact of non-unique names.
From: Mathieu Gagné [mailto:mgagne at iweb.com]
Sent: Thursday, December 11, 2014 3:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group
On 2014-12-11 8:43 AM, Jay Pipes 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.
We recently had an issue in production where a user had 2 "default"
security groups (for reasons we have yet to identify). For the sack of
completeness, we are running Nova+Neutron Icehouse.
When no security group is provided, Nova will default to the "default"
security group. However due to the fact 2 security groups had the same
name, nova-compute got confused, put the instance in ERROR state and
logged this traceback :
NoUniqueMatch: Multiple security groups found matching 'default'. Use
an ID to be more specific.
I do understand that people might wish to create security groups with
the same name.
However I think the following things are very wrong:
- the instance request should be blocked before it ends up on a compute
node with nova-compute. It shouldn't be the job of nova-compute to find
out issues about duplicated names. It should be the job of nova-api.
Don't waste your time scheduling and spawning an instance that will
never spawn with success.
- From an end user perspective, this means "nova boot" returns no error
and it's only later that the user is informed of the confusion with
security group names.
- Why does it have to crash with a traceback? IMO, traceback means "we
didn't think about this use case, here is more information on how to
find the source". As an operator, I don't care about the traceback if
it's a known limitation of Nova/Neutron. Don't pollute my logs with
"normal exceptions". (Log rationalization anyone?)
Whatever comes out of this discussion about security group name
uniqueness, I would like those points to be addressed as I feel those
aren't great users/operators experience.
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev