No logging appearing on the console any more?

[mtustin-handy]

Running the scheduler used to spit out logs of information. It now spits out nothing other than the airflow header. Also, I am able to verify that when I put logging in airflow_local_settings that I get log messages output on the console.

Using commit edd0fd3

[mistercrunch]

@svendx4f , are we missing something?

Should I revert #740 ?

[mistercrunch]

@mtustin-handy , fyi airbnb runs the airbnb_prod branch in production and master has become more of a trunk

[mtustin-handy]

@mistercrunch Good to know.

[mtustin-handy]

@mistercrunch @svendx4f If I replace log_to_stdout with an empty implementation, I get log output. Accordingly, there's definitely a problem there.

[mtustin-handy]

@mistercrunch @svendx4f Fix in pr: #752

[sv3ndk]

Hi,

Sorry about this, yes, I understand there's indeed something wrong.

The log_to_stdout was already there before, in cli.py, the new version is almost identical, and the logs don't seem to be missing in Travis.

The log setup is duplicated in several places, in cli.py, airflow.py and utils.py, I guess I missed something somewhere.

I'm having atm, give me a sec..

[mtustin-handy]

@svendx4f Whether or not log_to_stdout was there previously, it's completely unnecessary to attempt reinitialisation in all those places. It's much cleaner to just initialise once, in a place that can be reasonably customised. The code in #752 is cleaner, allows local overrides, and works.

[sv3ndk]

Thanks for looking into that @mtustin-handy, I'm happy to hear your PR is solving this.

The logic in cli.py was initialising the logs in several places and in different ways, among other things with different logging format.

I totally agree it's cleaner to have one single configuration approach for the whole project.

I think we now have the loggers named after the containing file instead of the class as before (cf this travis log) , it is the intended behaviour ? Or is the behaviour different in your runtime?

[mtustin-handy]

Now the loggers are named after the fully qualified names of the classes.
That is, module + class.

On Thursday, 10 December 2015, Svend Vanderveken notifications@github.com
wrote:

Thanks for looking into that @mtustin-handy
https://github.com/mtustin-handy, I'm happy to hear your PR is solving
this.

The logic in cli.py was initialising the logs in several places and in
different ways, among other things with different logging format.

I totally agree it's cleaner to have one single configuration approach for
the whole project.

I think we now have the loggers named after the containing file instead of
the class as before (cf this travis log
https://travis-ci.org/airbnb/airflow/jobs/96166494#L1204) , it is the
intended behaviour ? Or is the behaviour different in your runtime?

—
Reply to this email directly or view it on GitHub
#749 (comment).

Want to work at Handy? Check out our culture deck and open roles
http://www.handy.com/careers
Latest news http://www.handy.com/press at Handy
Handy just raised $50m
http://venturebeat.com/2015/11/02/on-demand-home-service-handy-raises-50m-in-round-led-by-fidelity/ led
by Fidelity

[mtustin-handy]

I'm closing as the fix has been merged to master