Bug 1162317
| Summary: | [RFE] track system firmware version in inventory | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Arthur Benoit <abenoit> |
| Component: | web UI | Assignee: | Dan Callaghan <dcallagh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Anwesha Chatterjee <achatter> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | 0.18 | CC: | achatter, apowers, dcallagh, ebaak, jburke, pbunyan, rjoost |
| Target Milestone: | 25.0 | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-03-19 04:18:30 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
Arthur Benoit
2014-11-10 20:14:58 UTC
Jeff, I'm trying to simplify bios update version tracking. If beaker could track bios updates I think it would be very helpful to users. Currently we log bios updates in RT requests that are closed. When tickets have 35 systems that need to be updated, adding the system specific information becomes chaotic and makes finding information very hard. If the versioning information is kept in beaker it's per system, which makes it easier to find. Very often we get vendor upgrade CD's or bundles that don't show us the new or old bios versions while doing the updates. The installer is required to go into bios (before and after upgrades) and transcribe the versions from the bios setup window into our RT tickets. This increases the chance of mistakes while recording the versions. My request was for a way to allow for more consistent tracking of BIOS versions using a beaker history. I'm open to any ideas. Thanks, Arthur Arthur, I think it is great that you are trying to simplify the process. I was only pointing out that your request of having Beaker do it, doesn't solve the problem. It just moves it from a RT/bookeeping issue to a Beaker/bookeeping issue. Since in your request the information is collected only when you run a inventory job in Beaker. My examples in Comment #1 was only to show you that we do already collect the data in Beaker, but it is only collected by 'kernelinstall' task. So another task would have to be added or you could modify the /distribution/install Sysinfo task to collect the same data that kernelinstall Sysinfo collects. However it is not displayed on the System page. Regards, Jeff The "force" option on hostRequires makes it possible to inventory Manual and Broken systems now, so it's much simpler to keep these kinds of inventory task based records up to date than it used to be. Bug 1121462 (adding a "bkr update-inventory" CLI command) and bug 846185 (providing a "1 click" mechanism to run inventory jobs through the web UI) are designed to make it even easier to run inventory jobs on a system. Yes and we could even take it to further extremes -- almost all of beaker-system-scan is quite fast and non-destructive (the multipath stuff is the only exception) so we could consider running it in *every* recipe in /distribution/install. At least in future when it is lshw-based and we can easily support all platforms+arches. The problem of stale inventory data is not really specific to this request (firmware versions) either, it applies to all the inventory info in Beaker. So I don't think we should let that stop us from recording as much useful info as we can. As far as collecting firmware versions... We have another open RFE, bug 1112439, for collecting firmware type on x86 (EFI vs. BIOS-compatible) and in that I also mentioned the possibility of collection more details like firmware versions. So this RFE is really the successor to that one. *** Bug 1195344 has been marked as a duplicate of this bug. *** Paul gave some good hints about how to capture the version info using dmidecode: https://bugzilla.redhat.com/show_bug.cgi?id=1195344#c0 Dan, Is this still on the radar? Best, -pbunyan We haven't made any progress on this yet. We are still working towards switching beaker-system-scan to using lshw, once that is done we can start looking at what new data we can collect. Lshw already reports some info about firmware version from DMI (and device tree on ppc). *** Bug 1331385 has been marked as a duplicate of this bug. *** *** Bug 1509794 has been marked as a duplicate of this bug. *** Shawn Doherty and Jonathan Toppins have contributed patches to have Beaker track the firmware version (of both the system firmware itself, as well the firmware of any other devices that can report their version like NICs): https://gerrit.beaker-project.org/c/5808/ https://gerrit.beaker-project.org/c/5807/ The original request in this bz also mentions tracking the *previous* firmware version, but I would like to tackle that separately because it's (surprisingly) a fair bit harder. I forgot that this also needs a testing build of beaker-system-scan... The patched build is beaker-system-scan-2.2-1.git.3.eb30042 and it is now available here: https://beaker-project.org/yum/harness-testing/ and I've synced it down to beaker-devel as well. Verified that after running a hardware scan on hp-dl160gen9-04.rhts.eng.bos.redhat.com the firmware version for its BIOS is updated Beaker 25.0 has been released. Release notes are available upstream: https://beaker-project.org/docs/whats-new/release-25.html |