Red Hat Bugzilla – Bug 505666
[Stratus 5.7 bug] rebootpkgs & remove_blacklist should be mutable lists
Last modified: 2013-03-14 16:03:40 EDT
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
--- __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 @@
-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"]
# FIXME: this is pulled directly from yum/output.py just for debugging
Proposing for RHEL 5.5, since this is a feature request.
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 "?".
Deferring to RHEL 5.6 with OK from Stratus.
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?
(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
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.
> 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:
# 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).
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.
(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()
Engineering has deferred this to RHEL 5.6 due to resources and capacity.
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.
This component has not been approved for RHEL 5.7. Moving this to RHEL 5.8 for
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.
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.
Has this been proposed as an RFE or a Bug? I see mention of "Feature" earlier in the ticket. Can we please clarify?
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.
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.