Respect documentation on passive log level

[sgugger]

What does this PR do?

The documentation states that setting a log_level to "passive" in the training arguments won't touch the log level, but this is not the case. Currently, setting log_level to "passive" is the same as setting it to "info".
Likewise, setting log_level_replica to "passive" is the same as setting it to "warning".

This PR fixes this and changes the default of log_level_replica to "warning" to have the same default for it. The question is whether we should change the default of log_level to "info" to have the same behavior as before, or leave it as is which would set it to warning unless the user has set their own Transformers verbosity to info like in the examples.

Related to #20154

[HuggingFaceDocBuilderDev]

The documentation is not available anymore as the PR was closed or merged.

[LysandreJik]

Your change looks good! I wouldn't change the default to INFO for the log level, leaving it as the default gotten from logging.get_verbosity() sounds good to me.

[stas00]

I mostly agree with Lysandre

In fact I'd have used ERROR for replicas, since if you have 256 gpus you really don't want to see the same warning 256 times. But we have a tool to override, so WARNING is probably ok.

[stas00]

while at it could you please remind me what does passive actually imply?

a 'passive' level which doesn't set anything and lets the application set the level

how does the application set the level? which application? perhaps we need a small example?

[stas00]

Thank you for clarifying the doc, Sylvain.

In retrospect this default should have just been None as it doesn't do anything.

[sgugger]

Probably yes.

[stas00]

Hmm, this broke many deepspeed tests that were relying on info log level in deepspeed.

now deepspeed is no longer logging info "DeepSpeed info: version={}, git-hash={}, git-branch={}"

and thus the tests fail as it is looking for this string to tell DS is running.

Now, why would this change impact an underlying component I wonder.

[stas00]

OK, I now have to explicitly pass ` log_level="info" to trainer args to have the previous functionality. This looks like a BC breakage, no?

I adapted get_regression_trainer to have the original behavior here: #21769 so it's all back to working.

[sgugger]

Yes, I did mention it changed the behavior in the description of the PR and asked for how to proceed. You and Lysandre both agreed the break was worth it in this case.

[stas00]

Totally, Sylvain. I guess I struggle to understand when a BC breakage is ok and when it's not.