More details...... I wanted to make a minimal replicator for this issue. I started with the command 'keystone-manage db_version', as this seemed to be the 'simplest' example I could find that would replicate the exception. I then started hacking out code, with the idea that if I took out code, and the exception still occured, I didn't need the removed code for the replicator. Where I got to was:
In keystone/cmd/mangage.py I could remove everything except:
from keystone.cmd import cli
and from keystone/cmd/cli.py the only line needed to replicate the issue is:
from keystone.server import backends
and if we look in keystone/server/backends.py it's the line:
from keystone import application_credential
where in keystone/application_credential/__init__.py it's just this line:
from keystone.application_credential.core import *
and then keystone/application_credential/core.py it's this line that is the one that causes the issue:
from keystone import notifications
HOWEVER: in keystone/notifications.py , it's exactly these two lines:
import flask
import oslo_messaging
that are necessary for the exception. Remove either of those two, and things work fine.
In the attached replicator code 'replicator.py', you can find my replacement for keystone/notifications.py as 'replicator_lib.py'. You'll note that replicator_lib.py needs to contain the two lines:
import flask
import oslo_messaging
I note, however, that if you bring the importing of flask and oslo_messaging into replicator.py, things work again. The lines *must* be in something that is imported in order to trigger the exception.
To run the replicator:
virtualenv foo
source foo/bin/activate
pip install flask oslo_messaging
python3 replicator.py
Note that nothing of keystone is actually used here.
And now, if you want the exception to go away, the following change will work. Add the line:
import flask
into keystone/application_credential/core.py after the line:
from keystone import notifications
And then 'keystone-manage db_sync' et al. will work without tossing an
exception. Why? I have absolutely no clue.
More details...... I wanted to make a minimal replicator for this issue. I started with the command 'keystone-manage db_version', as this seemed to be the 'simplest' example I could find that would replicate the exception. I then started hacking out code, with the idea that if I took out code, and the exception still occured, I didn't need the removed code for the replicator. Where I got to was:
In keystone/ cmd/mangage. py I could remove everything except: server/ backends. py it's the line: credential application_ credential/ __init_ _.py it's just this line: application_ credential. core import * application_ credential/ core.py it's this line that is the one that causes the issue: notifications. py , it's exactly these two lines:
from keystone.cmd import cli
and from keystone/cmd/cli.py the only line needed to replicate the issue is:
from keystone.server import backends
and if we look in keystone/
from keystone import application_
where in keystone/
from keystone.
and then keystone/
from keystone import notifications
HOWEVER: in keystone/
import flask
import oslo_messaging
that are necessary for the exception. Remove either of those two, and things work fine.
In the attached replicator code 'replicator.py', you can find my replacement for keystone/ notifications. py as 'replicator_ lib.py' . You'll note that replicator_lib.py needs to contain the two lines:
import flask
import oslo_messaging
I note, however, that if you bring the importing of flask and oslo_messaging into replicator.py, things work again. The lines *must* be in something that is imported in order to trigger the exception.
To run the replicator:
virtualenv foo
source foo/bin/activate
pip install flask oslo_messaging
python3 replicator.py
Note that nothing of keystone is actually used here.
And now, if you want the exception to go away, the following change will work. Add the line:
import flask
into keystone/ application_ credential/ core.py after the line:
from keystone import notifications
And then 'keystone-manage db_sync' et al. will work without tossing an
exception. Why? I have absolutely no clue.