6:58 p.m.
On 2019-08-26 15:56, Martin van Es wrote:
Hi Scott (and Giuseppe)
The idea is that by default you use your own scheduler.
Here is what I am doing right now with pyFF
(though I just found a
somewhat critical issue that I am going to report on/ask for help soon):
Thx for the fast responses! I'm a quite bit further now!
I discovered three importand things:
1. PYFF_UPDATE_FREQUENCY defaults to 0 if not set. When set to anything other
than 0, it forces an internal request on PYFF_PUBLIC_URL/api/call/update to
bootstrap pipeline parsing. Without it, pyff won't give any decent answer.
2. Without PYFF_UPDATE_FREQUENCY one needs to call
POST PYFF_PUBLIC_URL/api/
call/update oneself, which results in a "404 Not found". THIS IS A RED
HERRING, the update succeeded anyway (my oh my).
Documentation is admittedly a bit behind... but you should get a 404
there if your pipeline is setup to have an 'update' entrypoint. What
does your pipeline look like?
3. After 2, or when supplying PYFF_UPDATE_FREQUENCY other than 0, I can now
succesfully retreive correctly signed sane md for one of the loaded entityID's
in my test pipeline (hurray).
But: I still don't understand, when booted with gunicorn (is this the best way
forward?) pyFF logging is absent. I still only see the gunicorn boot sequence
and then silence, no matter what I set PYFF_LOGLEVEL to, unless pyFF generates
an exception, which are shown e.g. when accessing PYFF_PUBLIC_URL/api/call/
update at start fails. Where's my normal logs? Is your --log-config logger.ini
the secret to this Scott?
Logging is a bit of a dark art in wsgi (at least to me) but if you set
PYFF_LOGGING to point to examples/debug.ini you'll see a lot more and
also hopefully understand what logging looks like.
Again docs is a bit behind...
Cheers Leif
Best regards,
Martin
_______________________________________________
Idpy-discuss mailing list
Idpy-discuss at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-discuss