Bug 232902

Summary:	Auto Apply Errata not working correctly.
Product:	[Retired] Red Hat Network	Reporter:	Clifford Perry <cperry>
Component:	RHN/Web Site	Assignee:	Kevin A. Smith <ksmith>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Preethi Thomas <pthomas>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rhn500	CC:	akrherz, duffy, newbery, rhn-bugs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
URL:	https://www.redhat.com/archives/rhn-users/2007-March/msg00059.html
Whiteboard:
Fixed In Version:	5.0.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-27 13:16:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	232426

Description Clifford Perry 2007-03-19 13:40:37 UTC

Description of problem:
Taken from a rhn-list posting and my own review. It seems that Auto Apply Errata
is not working as expected within RHN 5.0.0 since its release into production on
March 11th. 

I do not have full details yet, but sounds like it kicked in for this account
and scheduled the application of errata to *all* systems on the account, even
those where the errata was not appliciable, and also ignoring the flag for 'Auto
Apply Errata'. 

Creating this *public* bug for tracking. 

Cliff. 

Version-Release number of selected component (if applicable):


How reproducible:
Not sure yet
Report came from:
https://www.redhat.com/archives/rhn-users/2007-March/msg00059.html

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
I'm not sure whether this is a hosted or proxy issue and I'm not sure
if it is operator error or something else that caused it. We have a
hosted environment running a current release proxy server with custom
channels. A product enhancement errata was released for some of those
custom channels a couple of days ago and today it was scheduled for
every system subscribed to the pertinent channels (or so it seems at a
glance).

Question 1: Should this errata be scheduled for machines which don't
have any relevant package installed? It was but this seems silly. They
picked it up and failed to install it harmlessly.

Question 2: Should it be scheduled for systems with auto errata update
set to no? It was. I can't tell how the scheduling is done, it is
listed as (none).

Question 3: Should systems with this errata scheduled but which have
auto errata updates set to no pick up the package and install it when
doing the next rhn_check? They did. This caused major grief as it
broke openAFS in this case and it seems to me that this should not
have happened.

Can anyone shed any light on any of this for me? It has been an
immensely long week and I'm exhausted so maybe I'm not thinking too
clearly at the moment.

Thanks,
John

Comment 3 Clifford Perry 2007-03-19 16:31:45 UTC

Having reviewed, it seems that there is a bug in the background daemon that
schedules to application of 'Apply Auto Errata'. I have placed this bug onto the
must fix list for the next scheduled minor maintence release of the RHN Hosted
web site to get fixed. 

Cliff.

Comment 4 Kevin A. Smith 2007-03-20 19:42:13 UTC

* Fixed overly "generous" logic in the ErrataQueueWorker which was causing
auto-errata updates to be applied to too many machines.

Comment 6 Kevin A. Smith 2007-03-22 14:09:12 UTC

Suggested Test Plan:

1) Find an account which has errata auto-updates disabled.

2) Create and publish a new errata.

3) Wait for the errata to get applied.

You can monitor the progress of errata processing by:
 3a) Edit /usr/share/rhn/classes/log4j.properties on scripts.back-webqa.redhat.com
 3b) Add the following line:
     log4j.logger.com.redhat.rhn.task.ErrataCacheTask=DEBUG
 3c) Bounce taskomatic: /sbin/service taskomatic restart
 3d) Monitor the /var/log/rhn/rhn_taskomatic_daemon.log file

4) Once errata processing is complete, verify that the server used in step #1
does not have the errata scheduled.

Comment 7 Preethi Thomas 2007-03-22 18:18:35 UTC

fails qa.
looks like its not fixed.
ksmith is already looking in to it.

Comment 8 Kevin A. Smith 2007-03-22 20:40:31 UTC

Ok. Let's try this again with a different test path. We'll need to simulate the
effects of prod-ops' errata scripts so some manual database munging is involved.

1) Use the /svn/trunk/eng/backend/server/test/test_errata_import_webqa.py script
to create a new errata. Change the advisory name before running the script. I've
used the house number part of my address to try and insure uniqueness.

2) After the script has run, execute the following SQL query against the webqa
database:

select id from rhnErrata where created > sysdate - 1 and created < sysdate and
advisory like '%ADVISORY_NAME%'

Note: Replace the term ADVISORY_NAME with the unique value you selected in step
1. Make sure to leave the percent signs in place otherwise the query will not
work correctly.

3) Jot down the id returned from the query.

4) Create a work entry for taskomatic so it can process the new errata. This is
normally done by prod-ops' scripts, but we'll have to simulate it here.

insert into rhnErrataQueue values (ERRATA_ID, sysdate, sysdate, sysdate);
commit;

Note: Replace the term ERRATA_ID with the id from step 3.

5) Wait for taskomatic to process this record. I'd suggest waiting 15-20 minutes.

6) Login to an account which has servers with auto errata updates disabled.

7) Verify that these servers _do not_ have a pending errata action for the newly
created errata.

Comment 9 Preethi Thomas 2007-03-23 12:50:13 UTC

verified.

Thanks kevin for the detailed test plan.

Comment 10 Bret McMillan 2007-03-26 13:41:48 UTC

I've checked this in stage using my own account... 

System 1007229597 has a bunch of errata scheduled (correct)
System 1007229598 does *not* have a bunch of errata scheduled (correct)

Comment 11 Bret McMillan 2007-03-26 13:49:17 UTC

Moving to RELEASE_PENDING

Comment 13 daryl herzmann 2007-03-29 20:05:29 UTC

Why no announcement to the community about this?

Comment 14 Máirín Duffy 2007-03-29 21:01:19 UTC

Daryl, can you elaborate?

Comment 15 daryl herzmann 2007-03-29 21:09:42 UTC

Hi Máirín,

I did on the email list.

thanks,
  daryl

Comment 16 daryl herzmann 2007-11-09 16:39:59 UTC

Greetings,

This problem appears to be back as I have most of my auto-apply systems yet to
apply RHEL5.1 .. Some SSIDs for ya:

1007413619
1008254853

(I have lots more if necessary)

daryl

Comment 17 Máirín Duffy 2007-11-09 16:50:09 UTC

see bug 373131 re: comment #16