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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
