Bug 1329001

Summary: [RFE] subscription-manager refresh should do more
Product: Red Hat Enterprise Linux 7 Reporter: John Sefler <jsefler>
Component: subscription-managerAssignee: candlepin-bugs
Status: CLOSED WONTFIX QA Contact: John Sefler <jsefler>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: crog, redakkan, wpoteat
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 07:41:10 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:

Description John Sefler 2016-04-20 21:10:16 UTC
Description of problem:
Currently there is a module called subscription-manager refresh.  Here is the help and man page info for it....

[root@dell-per320-01 ~]# subscription-manager refresh --help | head -4
Usage: subscription-manager refresh [OPTIONS]

Pull the latest subscription data from the server

[root@dell-per320-01 ~]# man subscription-manager | grep REFRESH -A10
   REFRESH OPTIONS
       The  refresh  command  pulls the latest subscription
       data from the server. Normally, the system polls the
       subscription management service at a set interval (4
       hours by default) to check for any  changes  in  the
       available  subscriptions. The refresh command checks
       with the subscription management service right then,
       outside the normal interval.


       This command has no options.

When I run this oommand and tail the requests that it makes, this is what I see....

[root@dell-per320-01 ~]# subscription-manager refresh
All local data refreshed
[root@dell-per320-01 ~]# 
[root@dell-per320-01 ~]# tail -f /var/log/rhsm/rhsm.log | egrep 'Making request|Running'
2016-04-20 16:57:01,751 [DEBUG] subscription-manager:29966 @connection.py:523 - Making request: GET /subscription/
2016-04-20 16:57:02,184 [DEBUG] subscription-manager:29966 @connection.py:523 - Making request: GET /subscription/status
2016-04-20 16:57:02,635 [DEBUG] subscription-manager:29966 @connection.py:523 - Making request: GET /subscription/consumers/111f75ea-00a9-47d9-bc07-917f201adc2f/certificates/serials
2016-04-20 16:57:03,182 [DEBUG] subscription-manager:29966 @connection.py:523 - Making request: GET /subscription/consumers/111f75ea-00a9-47d9-bc07-917f201adc2f/compliance


More often than, what I really want refresh to do is run /usr/libexec/rhsmcertd-worker whose man page description is similar to refresh.

Here's what /usr/libexec/rhsmcertd-worker does...
[root@dell-per320-01 ~]# /usr/libexec/rhsmcertd-worker
Updating entitlement certificates & repositories
Total updates: 0
Found (local) serial# [6885349221265790873L]
Expected (UEP) serial# [6885349221265790873]
Added (new)
  <NONE>
Deleted (rogue):
  <NONE>
Report
        status: 1
        updates: []
        exceptions: 
        
Fact updates
        status: None
        updates: []
        exceptions: 
        
Package profile updates
        status: 0
        updates: []
        exceptions: 
        
Installed Products
        status: 0
        updates: []
        exceptions: 
        
[root@dell-per320-01 ~]# 
[root@dell-per320-01 ~]# tail -f /var/log/rhsm/rhsm.log | egrep 'Making request|Running'
2016-04-20 17:00:16,438 [DEBUG] rhsmcertd-worker:29992 @connection.py:523 - Making request: GET /subscription/consumers/111f75ea-00a9-47d9-bc07-917f201adc2f/certificates/serials
2016-04-20 17:00:21,159 [DEBUG] rhsmcertd-worker:29992 @connection.py:523 - Making request: GET /subscription/consumers/111f75ea-00a9-47d9-bc07-917f201adc2f
2016-04-20 17:00:24,779 [DEBUG] rhsmcertd-worker:29992 @connection.py:523 - Making request: GET /subscription/
2016-04-20 17:00:25,205 [DEBUG] rhsmcertd-worker:29992 @connection.py:523 - Making request: GET /subscription/consumers/111f75ea-00a9-47d9-bc07-917f201adc2f/content_overrides
2016-04-20 17:00:26,825 [DEBUG] rhsmcertd-worker:29992 @connection.py:523 - Making request: GET /subscription/consumers/111f75ea-00a9-47d9-bc07-917f201adc2f/release
2016-04-20 17:00:34,208 [DEBUG] rhsmcertd-worker:29992 @plugins.py:769 - Running update_content_hook in container_content.ContainerContentPlugin
2016-04-20 17:00:34,279 [DEBUG] rhsmcertd-worker:29992 @hwprobe.py:772 - Running 'virt-what'


You see from the log about that it does more of what I expect subscription-manager refresh to do.


My proposal is to add a new option to subscription-manager refresh that simply calls /usr/libexec/rhsmcertd-worker
   subscription-manager refresh --more

And you could also have an option that refreshes even more than that which calls /usr/libexec/rhsmcertd-worker --autoheal
   subscription-manager refresh --all




Note: the --more and --all options that I gave above are poorly worded.  We need to come up with a better value.  My point is that subscription-manager is what our customers are running and refresh is what they find when they look for help, but it often fails to do what they expect it to do.  Providing additional options to subscription-manager refresh that wrap /usr/libexec/rhsmcertd-worker will make the refresh module more powerful.


Version-Release number of selected component (if applicable):
[root@dell-per320-01 ~]# rpm -q subscription-manager
subscription-manager-1.15.9-15.el7.x86_64

Comment 1 Chris "Ceiu" Rog 2016-08-03 13:45:10 UTC
A slight enhancement has been made to the refresh command, somewhat in line with this RFE: subman refresh will now also trigger entitlement regeneration, which implicitly refreshes/resynchronizes the repos for any attached subscriptions.


commit 0a2f90c86f4d7a6aec88a6fe3d3e91bbff6b2e8f
Author: Chris Rog <crog>
Date:   Fri Jul 29 12:21:22 2016 -0400

    1360909: The refresh command now requests entitlement cert regeneration

    - When the refresh command is issued on the CLI, subman will request
      entitlement certificate regeneration (lazily) for the active consumer

Comment 3 RHEL Program Management 2020-12-15 07:41:10 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.