Bug 1040619

Summary: [PATCH] add 'errors only' reporting option for yum-cron
Product: Red Hat Enterprise Linux 7 Reporter: jcpunk
Component: yumAssignee: Valentina Mukhamedzhanova <vmukhame>
Status: CLOSED CURRENTRELEASE QA Contact: Karel Srot <ksrot>
Severity: low Docs Contact:
Priority: low    
Version: 7.0CC: admiller, csieh, extras-orphan, ffesti, firas.alkafri, james.antill, jzeleny, ksrot, misterbonnie, packaging-team-maint, riehecky, rvokal, tla
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: yum-3.4.3-112.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 999155 Environment:
Last Closed: 2014-06-13 10:56:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description jcpunk 2013-12-11 17:31:14 UTC 
+++ This bug was initially created as a clone of Bug #999155 +++

Description of problem: I've got a large number of workstations that all have yum-cron enabled for package installation.  I don't care if they installed the updates successfully - but I do care if they didn't.

I've attached a patch to allow you to only report errors with yum-cron


Version-Release number of selected component (if applicable): 3.4.3-106.fc19


How reproducible: 100%

Steps to Reproduce:
1. run yum-cron on a system where it errors
2. run yum-cron on a system where it succeeds
3. wish you could only get reports from #1 

Actual results:
reporting always occurs

Expected results:
The ability to trim down what it reports to just systems with errors

Additional info:

A patch to add this behavior is attached.

--- Additional comment from Zdeněk Pavlas on 2013-08-26 07:40:05 EDT ---

http://lists.baseurl.org/pipermail/yum-devel/2013-August/010334.html

I've already written something similar, but this gets rid of more messages, and correctly handles the self.output==[] case, so I like it. Do you think that adding an extra option is better than just honoring the loglevel settings?

--- Additional comment from  on 2013-08-26 09:06:01 EDT ---

Using loglevel for this seems great to me!  Just need to make sure that the reduction in reporting is well documented so everyone knows how to get this behavior.

--- Additional comment from  on 2013-10-21 15:50:55 EDT ---

Just checking back in, log_level seems like the right direction for this.  Any hope of getting your patches at : http://lists.baseurl.org/pipermail/yum-devel/2013-August/010334.html merged?
Comment 2 Zdeněk Pavlas 2013-12-13 10:25:09 UTC 
I'd like to resolve this in the same way we did in Fedora, by new handling of yum-cron.conf options.  Previously update_messages=NO acted as a master switch, turning off anything but updating the metadata cache.  Backporting these two commits should be enough:

commit 587288e13575b6f3f6c8cdc1a13abe9117444636
Author: Zdenek Pavlas <zpavlas>
Date:   Fri Oct 11 09:28:57 2013 +0200

    yum-cron: support download/install with update_messages==False. BZ 1018068
    
    (download_updates or apply_updates) now implies that yum-cron should
    do the updates processing, too.  The update_messages==False case is
    then used to make yum-cron less chatty.


commit e1db5d6a94dee861d1fa0552277bc03f037c6e3a
Author: Zdenek Pavlas <zpavlas>
Date:   Tue Dec 10 08:47:48 2013 +0100

    yum-cron: stderr/email: no output if no messages
Comment 8 Ludek Smid 2014-06-13 10:56:28 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.