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/


OpenStack-dev mailing list

Reply via email to