Bug 1040619

Summary:	[PATCH] add 'errors only' reporting option for yum-cron
Product:	Red Hat Enterprise Linux 7	Reporter:	jcpunk
Component:	yum	Assignee:	Valentina Mukhamedzhanova <vmukhame>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Karel Srot <ksrot>
Severity:	low	Docs Contact:
Priority:	low
Version:	7.0	CC:	admiller, csieh, extras-orphan, ffesti, firas.alkafri, james.antill, jzeleny, ksrot, misterbonnie, packaging-team-maint, riehecky, rvokal, tim.lauridsen
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:
Embargoed:

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.