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. --Rocky -----Original Message----- From: Mathieu Gagné [mailto:mga...@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.  http://paste.openstack.org/show/149618/ -- Mathieu _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev