I encountered the same problem when I run keystone with eventlet server by
using *keystone-all* command.
The failure caused by func *load_driver* in *keystone.common.manager*.
try:
driver_manager = stevedore.DriverManager(namespace,
driver_name,
invoke_on_load=True,
invoke_args=args)
return driver_manager.driver
except RuntimeError:
# Ignore failure to load driver using stevedore and continue on.
pass
stevedore failed to load the module, and the RuntimeError's error message
is:
No 'keystone.identity' driver found, looking for 'sql'
while 'keystone.identity' is the value of namespace, and 'sql' is the value
of driver, boht of them are right. I also check the setup.cfg file, it
contains the right lines:
keystone.identity =
ldap = keystone.identity.backends.ldap:Identity
sql = keystone.identity.backends.sql:Identity
Then I build another environment by cloning newest repo and reinstall the
virtualenv. Then, the server starting successfully. *So, I don't know why
stevedore failed.*
But I indeed found there is a bug: If stevedore failed to load a driver,
the backward way doesn't help:
def _load_using_import(driver_name, *args):
return importutils.import_object(driver_name, *args)
# For backwards-compatibility, an unregistered class reference can
# still be used.
return _load_using_import(driver_name, *args)
These code will try to import a driver_name = 'sql', and it failed.
On Sun, May 17, 2015 at 4:25 PM Chenhong Liu <liuchenh...@unitedstack.com>
wrote:
>
> I encountered the same problem when I run keystone with eventlet server by
> using *keystone-all* command.
>
> The failure caused by func *load_driver* in *keystone.common.manager*.
>
> try:
> driver_manager = stevedore.DriverManager(namespace,
> driver_name,
> invoke_on_load=True,
> invoke_args=args)
> return driver_manager.driver
> except RuntimeError:
> # Ignore failure to load driver using stevedore and continue on.
> pass
>
> stevedore failed to load the module, and the RuntimeError's error message
> is:
> No 'keystone.identity' driver found, looking for 'sql'
> while 'keystone.identity' is the value of namespace, and 'sql' is the
> value of driver, boht of them are right. I also check the setup.cfg file,
> it contains the right lines:
>
> keystone.identity =
> ldap = keystone.identity.backends.ldap:Identity
> sql = keystone.identity.backends.sql:Identity
>
> Then I build another environment by cloning newest repo and reinstall the
> virtualenv. Then, the server starting successfully. *So, I don't know why
> stevedore failed.*
>
> But I indeed found there is a bug: If stevedore failed to load a driver,
> the backward way doesn't help:
>
> def _load_using_import(driver_name, *args):
> return importutils.import_object(driver_name, *args)
>
> # For backwards-compatibility, an unregistered class reference can
> # still be used.
> return _load_using_import(driver_name, *args)
>
> These code will try to import a driver_name = 'sql', and it failed.
>
> On Sun, May 17, 2015 at 6:55 AM Scott Drennan <sco...@nuagenetworks.net>
> wrote:
>
>> Perhaps an obvious statement, but devstack master was working with
>> stable/kilo until recently, and as of today, it isn't any more (at least
>> for me).
>>
>> The devstack commit "Use stevedore for keystone backends" on 2014-05-15
>> changes the way backends are set, and when I did a fresh install today I
>> ended up with keystone.conf entries like this:
>>
>> [assignment]
>> driver = sql
>> ...
>> [identity]
>> driver = sql
>> ...
>> [token]
>> driver = sql
>>
>>
>> rather than fully specified module names (e.g. "driver =
>> keystone.identity.backends.sql.Identity")
>>
>> This caused keystone to fail, with errors
>> in /var/log/apache2/keystone.log like this:
>>
>> 2015-05-16 21:16:25.786955 mod_wsgi (pid=9296): Exception occurred
>> processing WSGI script '/var/www/keystone/main'.
>> 2015-05-16 21:16:25.787114 Traceback (most recent call last):
>> 2015-05-16 21:16:25.787189 File "/var/www/keystone/main", line 25, in
>> <module>
>> 2015-05-16 21:16:25.787409 application =
>> wsgi_server.initialize_application(name)
>> 2015-05-16 21:16:25.787437 File
>> "/opt/stack/keystone/keystone/server/wsgi.py", line 51, in
>> initialize_application
>> 2015-05-16 21:16:25.787600 startup_application_fn=loadapp)
>> 2015-05-16 21:16:25.787625 File
>> "/opt/stack/keystone/keystone/server/common.py", line 41, in setup_backends
>> 2015-05-16 21:16:25.787769 drivers = backends.load_backends()
>> 2015-05-16 21:16:25.787795 File
>> "/opt/stack/keystone/keystone/backends.py", line 39, in load_backends
>> 2015-05-16 21:16:25.787946 _IDENTITY_API = identity.Manager()
>> 2015-05-16 21:16:25.789345 File
>> "/opt/stack/keystone/keystone/common/dependency.py", line 131, in
>> __wrapped_init__
>> 2015-05-16 21:16:25.789519 init(self, *args, **kwargs)
>> 2015-05-16 21:16:25.789544 File
>> "/opt/stack/keystone/keystone/common/dependency.py", line 193, in wrapper
>> 2015-05-16 21:16:25.789570 self.__wrapped_init__(*args, **kwargs)
>> 2015-05-16 21:16:25.789584 File
>> "/opt/stack/keystone/keystone/identity/core.py", line 412, in __init__
>> 2015-05-16 21:16:25.790098 super(Manager,
>> self).__init__(CONF.identity.driver)
>> 2015-05-16 21:16:25.790124 File
>> "/opt/stack/keystone/keystone/common/manager.py", line 70, in __init__
>> 2015-05-16 21:16:25.790203 self.driver =
>> importutils.import_object(driver_name)
>> 2015-05-16 21:16:25.790226 File
>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line
>> 38, in import_object
>> 2015-05-16 21:16:25.790312 return import_class(import_str)(*args,
>> **kwargs)
>> 2015-05-16 21:16:25.790335 File
>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line
>> 27, in import_class
>> 2015-05-16 21:16:25.790358 __import__(mod_str)
>> 2015-05-16 21:16:25.790384 ValueError: Empty module name
>>
>>
>> After much head-scratching, since I'm not that familiar with keystone, I
>> figured out what was going on, corrected keystone.conf, and then went back
>> to devstack:stable/kilo, which behaves normally. I don't think there's an
>> issue here, but wanted to share in case someone else hits the same problem.
>>
>> cheers,
>> Scott
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
