Merge lp://qastaging/~doanac/lava-celery/logging-madness into lp://qastaging/lava-celery
| Status: | Rejected |
|---|---|
| Rejected by: | Michael Hudson-Doyle |
| Proposed branch: | lp://qastaging/~doanac/lava-celery/logging-madness |
| Merge into: | lp://qastaging/lava-celery |
| Diff against target: |
51 lines (+13/-4) 1 file modified
lava/celery/tasks.py (+13/-4) |
| To merge this branch: | bzr merge lp://qastaging/~doanac/lava-celery/logging-madness |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Linaro Validation Team | Pending | ||
|
Review via email:
|
|||
Description of the change
part of this hack feels ugly but the alternative was to have sys.stdout/
| Michael Hudson-Doyle (mwhudson) wrote | # |
Unmerged revisions
- 19. By Andy Doan
-
fix oddness with logging in tasks
The run_remote command wasn't handling all exceptions which under
certain circumstances made celeryd handle the exception. This is
somewhat okay, but the error gets logged in the worker. When you
think about the scenario where we run the dispatcher on a remote
system, the caller (scheduler in this case) will need to see these
types of errors.The other issue I hit was that when exceptions come from the
CloudifierDispatcher code, the stdout/stderr references get all
munged up in celery's twisted maze of redirecting its stdout to
its loggers. The only simple way out I found was with the hack:sys.stderr.
logger. root.handlers[ 0].stream = logging. sys.__stderr_ _ This also adds a bit of debbuging to indicate when a command is
received, what arguments were passed, and when it finished
Wow. I think you need to add some more comments! Feel free to swear in them :)
47 + if isinstance(
48 + sys.stderr.
this bit is the maddest of course. It's only due to celery that even sys.stderr.logger exists, right? When does celery do all this crap? Is it possible that we could get to this point in the code _without_ celery having done it?