Since commit 7f551ac1 (version 0.5.61 in November 2010) Beaker has not allowed key-value searches for MODULE, to prevent users from accidentally triggering a very expensive MySQL query (see bug 590723). This is an RFE to add a proper database table for kernel modules as an alternative to the MODULE key.
I wonder if we should track kernel modules at all. They are different depending on the release of the os, even between different releases..
I agree if do support this type of search that it should be in a proper table though.
(In reply to comment #1)
> I wonder if we should track kernel modules at all. They are different
> depending on the release of the os, even between different releases..
I imagine this is required because a particular module may be a driver for a potentially very long list of devices and the user may not care which one of them is available.
But this means it doesn't necessarily make sense to delete the existing modules when the inventory script is run. Or at least, not when it is run on a different release (or kernel version?). So should the table contain release/kernel/distro information?
As per discussions with Bill, closing as WONTFIX. Tracking kernel modules is not the best way to go about this, we should use Beaker's existing support for devices.
The web UI already supports searching by device driver (often equal to kernel module name) and PCI-ids. Bug 731615 is for adding the same to job xml.