Closed vooon closed 3 months ago
Seems a keystone related issue, as the target you set to Granian is not actually the WSGI application, but an executable script.
I'm pretty confident gunicorn or hypercorn will exhibit the same behaviour. Googling a bit it seems there's a way to serve the application direcly, see: https://freehackers.org/thomas/2016/04/17/using-keystone-mitaka-with-gunicorn-and-nginx/
Closing this, as there's nothing Granian can do in this case.
@gi0baro i managed to run it with custom wrapper (made of the original file):
import sys
import threading
from keystone.server.wsgi import initialize_public_application
application = None
app_lock = threading.Lock()
with app_lock:
# remove granian options
sys.argv = [sys.argv[0]]
if application is None:
application = initialize_public_application()
Where i can find doc on logging config?
@gi0baro i managed to run it with custom wrapper (made of the original file):
it should work also without the threading
lock, as application import is done on each worker (but those are separated processes, not threads) and from a single thread.
Where i can find doc on logging config?
We're still managing to write documentation, but the logging config in Granian relies on standard logging
dict config. You can look at the default configuration directly in the code: https://github.com/emmett-framework/granian/blob/master/granian/log.py#L28.
Access logs atoms are in the README instead.
Out of curiosity I've tried to use Granian to run OpenStack Keystone.
With default pbr generated wsgi file that's not possible:
I copied wsgi to have
.py
ext - module loads, but then problem came from argv's not cleaned from Granian options.