Bug 1478892

Summary: [RFE] Need an easy way to see when servers were last rebooted from Satellite 6, This lastboot information was available in Satellite 5
Product: Red Hat Enterprise Linux 8 Reporter: Ganesh Payelkar <gpayelka>
Component: subscription-managerAssignee: candlepin-bugs
Status: CLOSED ERRATA QA Contact: Red Hat subscription-manager QE Team <rhsm-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: bbuckingham, bkearney, cdonnell, cquinlan, csnyder, dchaudha, jsefler, mhulan, mvanderw, nshaik, sgraessl, tasander, tbrisker, tlestach, whitedm
Target Milestone: rcKeywords: FutureFeature, Reopened
Target Release: 8.1   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1739695 1742195 (view as bug list) Environment:
Last Closed: 2019-11-05 22:15:32 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:
Bug Depends On:    
Bug Blocks: 1739695, 1742195    

Comment 1 Ganesh Payelkar 2017-08-07 13:02:32 UTC
* We need an easy way to see when servers were last rebooted from Satellite 6

* Required to reboot systems as kernel, glibc, etc. updates.  

This lastboot information was available in Satellite 5 WebUI.


Satellite 5 having this feature : 

System Events
Checked In: 	07/13/2017
Registered: 	03/30/2017
Last Booted: 	a month ago
(Schedule System Reboot)

Comment 6 Bryan Kearney 2019-02-07 12:09:14 UTC
The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Comment 7 Bryan Kearney 2019-02-28 19:34:53 UTC
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

Comment 10 Chris Snyder 2019-05-30 18:12:11 UTC
The RFE has been merged upstream and should be included in the next build. As such, moving to MODIFIED.

Comment 12 whitedm 2019-07-18 13:20:28 UTC
Following.
I put in a support ticket feature request to RHEL on this a month or two back, as this information would be very helpful to us.

I'm encourage to see the last update from 5/30/2019!

Comment 13 John Sefler 2019-08-13 12:57:03 UTC
Verifying Version....
[root@kvm-02-guest25 ~]# rpm -q subscription-manager
subscription-manager-1.25.13-1.el8.x86_64

[root@kvm-02-guest25 ~]# rpm -q subscription-manager --changelog | grep 1478892
- 1478892: Add in a last_boot fact for parity with spacewalk facts


[root@kvm-02-guest25 ~]# subscription-manager facts | grep last_boot
last_boot: 2019-08-12 12:29:10


[root@kvm-02-guest25 ~]# cat /proc/uptime
87729.82 172917.26

^^^^^^^^ This is the time in seconds of uptime


[root@kvm-02-guest25 ~]# date -u
Tue Aug 13 12:51:40 UTC 2019

Aug 13 at 12:51 UTC minus 87729.82 divide by 60sec/min divide by 60min/hour = 24.4 hours which occurred on approximately Aug 12 at 12:30 UTC  which nicelu matches the last_boot fact.

NOTE: The last_boot fact does not explicitly state that it is reported in UTC. This might be a good idea.

Setting a NEEDINFO on the reporter to ask if the last_boot format is acceptable.  I would suggest adding UTC for clarity under a separate bug.

Comment 14 whitedm 2019-08-13 14:18:50 UTC
Forgive my ignorance, but I'm not entirely sure how Spacewalk handled this, and I'm still a little bit new to Satellite itself.

I realize I'm not the OP, but I subscribed to this bug, as I also want the feature.
In the support ticket that I opened with RHEL a few months ago, I was envisioning a column in the Satellite dashboard that would display uptime or the last_boot or whatever. In your example above, it appears to me that the subscription-manager facts command was run on the client.

Are these facts then somehow 'ingested' by Satellite for use on the Satellite server itself?
If I'm understanding correctly, the subscription-manager facts are indeed the types of information that are displayed on the Satellite dashboard for each host, i.e. if you navigate to Hosts -> All Hosts (https://example.satellite-URL.tld/hosts)

If so, that would be perfect.

A note to indicate that the timestamp is in UTC is certainly a good idea.
Alternatively, I don't think it would be too hard to modify the timestamp for whatever timezone Satellite uses?

Comment 15 John Sefler 2019-08-14 14:22:45 UTC
I decided to open Bug 1741219 requesting that the last_boot fact reported by subscription-manager facts should include "UTC" as a suffix to clarify the units of time.  That's the right thing for subscription-manager to do.

In response to comment 14...
Exactly how Satellite will display uptime/last_boot is up to the Satellite team and would be covered by a bugzilla/RFE opened against the "Red Hat Satellite 6" product.
This bugzilla 1478892 was used to make subscription-manager collect the system fact from each deployed instance of RHEL which will then be reported to Satellite.  Exactly how Satellite renders this info will be handled by a different team.

Moving NEEDINFO to bbuckingham who can better describe how this RFE will be integrated into Satellite.

Comment 17 errata-xmlrpc 2019-11-05 22:15:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3561