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
Doing this kind of change in 6.5 would be a major change, so while we know the logging API isn't ideal it is what it is atm. This is the kind of work that would require careful evaluation upstream, and so is unlikely to even make it into RHEL-7. I believe all the places print/write are used directly, they are within the "command" part of yum ... or one of the few cases where there was no logging object available.
Moving upstream
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.