Open Stack

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: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 [1]:

   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.

[1] http://paste.openstack.org/show/149618/

-- 
Mathieu

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev