Open Stack

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 <liuchenhong at 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 <scottd at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150517/09f43212/attachment.html>