Bug 861559

TESTED ON

Up to Fedora 17, yum-3.4.3-28.fc17.noarch

DESCRIPTION

yum python API is a good tool for programmatic automating yum tasks.

However, as far as logging is involved there is a gap between how pure API behaves and yum API behaves.

This was discussed briefly at yum list[1].

1. yum API initialize logging lazy

This means that application logging settings is overridden by yum when _internal_ objects are first created. 

This reverts back / overrides any application pre-setting of log behaviour.

2. yum API adds logging handlers

Python logging API[2] does not (per standard) allow handler replacement, so registering own handlers which write to private sources overrides/modifies application settings.

Expected: Handlers should not be added by an API, but by application.

3. yum API sets logging level

Setting severity combined with the above lazy(1) initialization overrides application setting.

Expected: Logging levels should be set by application.

4. yum API explicitly sets logging propagate property to "False"

Setting propagate by an API overrides application setting, and force application that wish to control all logs to know each of the logs in the name space to configure it separately.

Expected: All logs should be kept as propagate=True to allow customization while by default inherit settings from global logger.

5. yum API writes to stdout, stderr directly

'grep "print " *.py' shows places that instead of using logging, stdout/stderr are modified.

Expected: An API should not print any message to locations that are not controlled by application, it seems that all the output is related to logging so logging API should be used in these cases.

EXPECTED BEHAVIOUR

An API should not interact with user or write data to location not permitted by application.

An API should not alter application logging settings, and honour application logging settings.

An API should allow application to know which logs are being used so it can configure them properly, also in case of future log addition. For example, if a yum.component123.verbose log is added in future it should not break application logging settings and begin write messages to random locations. Keeping all logs as propagate is good for this case.

IMPLICATION

In order to properly use the API, the stdin/stdout/stderr should have been redirected during every API call and a global logger should have been register to handle the lazy initialization of logs.

An example of implementation is available at[3], it is working, however the setup_log_hook[4] should not have been required, same for the stdin/stdout/stderr manipulation[5].

Thank you for providing the yum python API!

---

[1] http://old.nabble.com/-python-API--logging-td34425322.html
[2] http://docs.python.org/library/logging.html
[3] http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vds_bootstrap/miniyum.py;hb=HEAD
[4] http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vds_bootstrap/miniyum.py;hb=HEAD#l302
[5] http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vds_bootstrap/miniyum.py;hb=HEAD#l199