Bug 505666

Summary: [Stratus 5.7 bug] rebootpkgs & remove_blacklist should be mutable lists
Product: Red Hat Enterprise Linux 5 Reporter: Rich Johnson <richard.johnson>
Component: pirutAssignee: James Antill <james.antill>
Status: CLOSED WONTFIX QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: bkearney, chas.horvath, dbayly, jparadis, kevin.paetzold, robert.evans, starlight, wgomerin
Target Milestone: alphaKeywords: OtherQA
Target Release: 5.7   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-14 20:03:40 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: 717402    
Attachments:
Description Flags
Extending list of "requires reboot" packages
none
yum plugin: ft-reboot-tracking.py none

Description Rich Johnson 2009-06-12 20:03:34 UTC
Description of problem:
The rebootpkgs & remove_blacklist lists are used to control display and behavior of pirut/pup.  They should be implemented as mutable lists instead of immutable tuples.  The rationale includes:
 - These lists are accessed using only list semantics.
 - Other rpms may require a reboot for proper operation--e.g. drivers, selinux packages that relabel the FS, kexec-tools--
 - The ability to add core storage drivers to the blacklist. 
 - yum plugins should be able to add to the list based on info found in a repository--e.g. updateinfo.xml.
 - The patch is trivial.

Version-Release number of selected component (if applicable):
bash# rpm -q pirut
pirut-1.3.28-13.el5

Additional info:

--- __init__.py 2008-03-19 17:08:12.000000000 -0400
+++ __init__.py.new     2009-06-12 15:39:27.000000000 -0400
@@ -66,10 +66,10 @@
 import rpm
 rpm.addMacro("_i18ndomains", "redhat-dist")
 
-remove_blacklist = ('yum', 'pirut', 'glibc', 'rpm-libs', 'rpm', 'kernel', 'kernel-xen', 'kernel-PAE')
-rebootpkgs = ("kernel", "kernel-smp", "kernel-xen-hypervisor", "kernel-PAE",
+remove_blacklist = ['yum', 'pirut', 'glibc', 'rpm-libs', 'rpm', 'kernel', 'kernel-xen', 'kernel-PAE']
+rebootpkgs = ["kernel", "kernel-smp", "kernel-xen-hypervisor", "kernel-PAE",
               "kernel-xen0", "kernel-xenU", "kernel-xen", "kernel-xen-guest",
-              "glibc", "hal", "dbus", "xen")
+              "glibc", "hal", "dbus", "xen"]
 
 class GraphicalYumBase(yum.YumBase):
     # FIXME: this is pulled directly from yum/output.py just for debugging

Comment 1 Andrius Benokraitis 2009-06-23 04:33:56 UTC
Proposing for RHEL 5.5, since this is a feature request.

Comment 2 RHEL Program Management 2009-11-06 19:22:24 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 3 Andrius Benokraitis 2009-11-10 17:55:51 UTC
Deferring to RHEL 5.6 with OK from Stratus.

Comment 5 RHEL Program Management 2009-11-11 06:19:53 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 8 James Antill 2009-11-12 15:40:30 UTC
Rich, your patch isn't bad per. se. however I can't see how you can use this patch without abusing a yum plugin to alter the internals of pirut ... is this what you are doing?

If so why don't you convert those variables from a tuple to a list in your plugin?

Comment 9 Rich Johnson 2009-11-12 17:24:59 UTC
(In reply to comment #8)
> Rich, your patch isn't bad per. se. however I can't see how you can use this
> patch without abusing a yum plugin to alter the internals of pirut ... is this
> what you are doing?
> 
> If so why don't you convert those variables from a tuple to a list in your
> plugin?  

I tried that.  The problem is that python reverts to the tuple when the pirut GUI gets around to annotating packages with that "reboot-required" icon. 

Besides, I prefer to think of it as "leverage" not "abuse" :-)

The long answer is:

Stratus' fault-tolerant system software includes kernel modules to monitor and recover from hardware faults.   Updates to these modules require a reboot to place them into service and the set of modules may vary over time.   

The desire is to have the pirut GUI  and the yum command dialog  treat _all_ packages that require a reboot in a manner identical to the way it treats the base packages  (kernel*, xen, glibc, etc.). 

You are correct that a yum plugin is involved.  This plugin has the resposibility to track and/or trigger required reboots.  Its hooks do the following:
  1.  at postreposetup:   extend the rebootpkgs list
  2.  at postresolve:  set a reboot-request flag if any of the packages in the transaction set requires a reboot
  3.  a posttrans hook to prompt the operator for a reboot to place the new packages into service as soon as possible
  4.  a close hook to do the deed.

I'd be happy to attach the plugin if desired.

Comment 10 James Antill 2009-11-12 18:32:32 UTC
> The problem is that python reverts to the tuple when the pirut
> GUI gets around to annotating packages with that "reboot-required" icon. 

 No, I think I see the problem though ... pup/puplet do:

from pirut import *

...which means if you do something like this in your plugin:

import pirut

# Use a set, because most things use "blah in rebootpkgs" etc.
if type(pirut.rebootpkgs) == type((,)):
  pirut.remove_blacklist = set(pirut.remove_blacklist)
  pirut.rebootpkgs = set(pirut.rebootpkgs)

...the "rebootpkgs" variable in pup/puplet will still be the original tuple value (as we can't changing the reference, just what reference the name points to).

Comment 11 Rich Johnson 2009-11-19 12:18:23 UTC
Created attachment 370325 [details]
Extending list of "requires reboot" packages

This image illustrates what I'm trying to achieve.  Those "lsb-ft..." kmods and hardened drivers are from a Stratus repository.  They require a reboot to take effect.  The desire is to have the pup/pirut GUI indicate that detail in a manner consistent with kernel and glibc.

Experience has been that having the plugin overlay pirut.rebootpkgs with a list does not yield the desired result.

Comment 12 Rich Johnson 2009-11-19 12:20:47 UTC
(In reply to comment #11)
> Experience has been that having the plugin overlay pirut.rebootpkgs with a list
> does not yield the desired result.  

...or plugin constructed set()

Comment 14 Andrius Benokraitis 2010-01-04 15:23:13 UTC
Engineering has deferred this to RHEL 5.6 due to resources and capacity.

Comment 16 Andrius Benokraitis 2010-10-05 18:22:54 UTC
I'm not sure this will ever get fixed in RHEL 5 unless pirut is going to be an approved package for updating. Deferring to 5.7.

Comment 17 Ronald Pacheco 2011-02-24 13:14:50 UTC
This component has not been approved for RHEL 5.7.  Moving this to RHEL 5.8 for
consideration then.

Comment 19 William Gomeringer 2011-07-05 17:05:12 UTC
Hi Rich,
It's been a while since your last update, but I was wondering if you could attach a plugin per (Comment #9), if you think it would be helpful.

Comment 20 Robert N. Evans 2011-07-08 11:46:27 UTC
Created attachment 511921 [details]
yum plugin: ft-reboot-tracking.py

Stratus uses this yum plugin with the pirut modification noted in the original bug description.  The plugin adds the selected Stratus packages to the pirut rebootpkgs list.  This plugin also manages reboots when upgrading Stratus packages via yum at the command line.  This works sufficiently for our needs.  Since the Stratus product for RHEL5 is no longer under active development, a fix for this pirut bug is not needed.

For Stratus' RHEL6 product, we have reverse-engineered the PackageKit yum plugin.  With this information, it is now possible to add updateinfo.xml to a Stratus repository and get the desired behavior from the PackageKit GUI.

Comment 21 William Gomeringer 2011-07-28 16:42:17 UTC
Has this been proposed as an RFE or a Bug? I see mention of "Feature" earlier in the ticket. Can we please clarify?

Thanks,
William

Comment 22 RHEL Program Management 2011-09-23 00:45:20 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 23 James Antill 2013-03-14 20:03:40 UTC
This request was evaluated by Red Hat Engineering for inclusion in a Red 
Hat Enterprise Linux maintenance release.

Red Hat does not currently plan to provide this change in a Red Hat 
Enterprise Linux update release for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in 
response to customer and partner requirements, Red Hat takes a 
conservative approach when evaluating enhancements for inclusion in 
maintenance updates for currently deployed products. The primary 
objectives of update releases are to enable new hardware platform 
support and to resolve critical defects.