unhashable type dict in create share type

[Silvan Kaiser]

Running Current devstack with manila setup the creation of new types via the cli client fails:

[ubuntu@maniladevstack screen(keystone_admin)]$ manila type-create anything False
ERROR: The server could not comply with the request since it is either malformed or otherwise incorrect.

Manila API Log outout shows:

2015-07-01 10:07:30.703 ERROR manila.api.openstack.wsgi [req-94e3b406-2406-4cd6-9832-3939fb2c0d79 33dba3a037354c89a5158f2656c87dd0 6445aaa68ae54d6faf4608780dee8bfb] Exception handling resource: unhashable type: 'dict'
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi Traceback (most recent call last):
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi File "/opt/stack/manila/manila/api/openstack/wsgi.py", line 736, in _process_stack
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi action_result = self.dispatch(meth, request, action_args)
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi File "/opt/stack/manila/manila/api/openstack/wsgi.py", line 812, in dispatch
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi return method(req=request, **action_args)
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi File "/opt/stack/manila/manila/api/contrib/types_manage.py", line 70, in _create
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi share_types.create(context, name, specs, is_public)
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi File "/opt/stack/manila/manila/share/share_types.py", line 42, in create
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi LOG.debug("Creating new share_type with name: %s and extra_specs: %s ", {name, extra_specs})
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi TypeError: unhashable type: 'dict'
2015-07-01 10:07:30.703 TRACE manila.api.openstack.wsgi

Looking at the code my guess is that the "name" variable seems to be the culprit. Either it should be handed into the method as a string value or it should have it's key value read for the debug output, shouldn't it?

[Silvan Kaiser (2-silvan)]

Uhm, besides my earlier guess, this might also be a bug in the manila client instead, who simply hand's in the wrong value for the name parameter...

[Valeriy Ponomaryov (vponomaryov)]

Can not reproduce on 'master' Manila code and python 2.7

[Silvan Kaiser (2-silvan)]

Ok, i'll check deeper into the environment and possible python lib/module version issues and get back here.
Thanks for checking!

[Silvan Kaiser (2-silvan)]

Could not reproduce this again. I'll revisit if i happen to meet it again but so far i think this was an environment issue.