Bug 861559 - yum python API should not write to stdout/stderr and allow setting log handlers
yum python API should not write to stdout/stderr and allow setting log handlers
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-29 03:21 EDT by Alon Bar-Lev
Modified: 2016-12-20 07:27 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 07:27:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alon Bar-Lev 2012-09-29 03:21:24 EDT
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
Comment 2 James Antill 2013-04-12 15:11:44 EDT
 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.
Comment 3 Alon Bar-Lev 2013-04-13 15:19:50 EDT
Moving upstream
Comment 4 Jan Kurik 2015-07-15 10:58:56 EDT
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
Comment 6 Fedora End Of Life 2016-11-24 05:49:31 EST
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.
Comment 7 Fedora End Of Life 2016-12-20 07:27:15 EST
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.

Note You need to log in before you can comment on or make changes to this bug.