Comment 3 for bug 1466485

Also, what looks like it's happening is that wsgi

1) wsgi tries starting a keystone worker
2) keystone does some things that affect process-global state, like registering config options, loading drivers
3) while this is going on, something else is mucking with installed python modules, causing keystone to raise exception
4) exception bubbles up and wsgi says it failed to start
5) wsgi tries starting keystone again in the same worker...
6) so keystone tries doing the same things again that affect process-global state, but keystone assumes starting with clean state,
     so it will just keep failing to start in this process.

So maybe keystone is doing something wrong here in that it can't clean up after itself, but the whole process is flawed and things are always going to be failing if the libraries are being changed from underneath the process.