Bug 1021771

Summary: subscription-manager status --ondate <ondate>displays the status of system <ondate> -1 day
Product: Red Hat Enterprise Linux 7 Reporter: Shwetha Kallesh <skallesh>
Component: subscription-managerAssignee: Carter Kozak <ckozak>
Status: CLOSED NOTABUG QA Contact: John Sefler <jsefler>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: bkearney, ckozak, dgoodwin, skallesh
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-22 12:39:22 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 Shwetha Kallesh 2013-10-22 04:11:12 UTC
Description of problem:
subscription-manager status --ondate displays the status of system <ondate> -1 day

Version-Release number of selected component (if applicable):
[root@localhost ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.8.29-1
subscription-manager: 1.10.4-1.git.0.e94d2a9.el7
python-rhsm: 1.10.3-1.git.0.6ac2883.el7


How reproducible:


Steps to Reproduce:
    [root@localhost ~]# subscription-manager register --org=admin --force
    Username: admin
    Password:
    The system has been registered with ID: fdf74286-f5ea-4d50-9ec1-ef053567cd7e
    [root@localhost ~]# subscription-manager list --avail --match-installed
    +-------------------------------------------+
        Available Subscriptions
    +-------------------------------------------+
    Subscription Name: Awesome OS for x86_64
    Provides:          Awesome OS for x86_64 Bits
    SKU:               awesomeos-x86_64
    Contract:          3
    Pool ID:           8ac6a3a241d9a9fe0141d9aabd060f81
    Available:         10
    Suggested:         2
    Service Level:    
    Service Type:      
    Multi-Entitlement: Yes
    Ends:              10/21/2014
    System Type:       Physical
     
    Subscription Name: Awesome OS for x86_64
    Provides:          Awesome OS for x86_64 Bits
    SKU:               awesomeos-x86_64
    Contract:          2
    Pool ID:           8ac6a3a241d9a9fe0141d9aabea11036
    Available:         5
    Suggested:         2
    Service Level:    
    Service Type:      
    Multi-Entitlement: Yes
    Ends:              10/21/2014
    System Type:       Physical
     
    [root@localhost ~]# subscription-manager attach --pool 8ac6a3a241d9a9fe0141d9aabd060f81 --quantity 1
    3 local certificates have been deleted.
    Successfully attached a subscription for: Awesome OS for x86_64
    [root@localhost ~]# subscription-manager list --installed
    +-------------------------------------------+
        Installed Product Status
    +-------------------------------------------+
    Product Name:   Awesome OS for x86_64 Bits
    Product ID:     100000000000002
    Version:        3.11
    Arch:           x86_64
    Status:         Partially Subscribed
    Status Details: Only covers 1 of 2 sockets.
    Starts:         10/21/2013
    Ends:           10/21/2014
     
    [root@localhost ~]# subscription-manager list --avail --ondate 2014-10-22 --match-installed
    +-------------------------------------------+
        Available Subscriptions
    +-------------------------------------------+
    Subscription Name: Awesome OS for x86_64
    Provides:          Awesome OS for x86_64 Bits
    SKU:               awesomeos-x86_64
    Contract:          3
    Pool ID:           8ac6a3a241d9a9fe0141d9aabb280ec0
    Available:         15
    Suggested:         2
    Service Level:    
    Service Type:      
    Multi-Entitlement: Yes
    Ends:              10/11/2015
    System Type:       Physical
     
    [root@localhost ~]# subscription-manager attach --pool 8ac6a3a241d9a9fe0141d9aabb280ec0
    Successfully attached a subscription for: Awesome OS for x86_64
    [root@localhost ~]# subscription-manager list --consumed
    +-------------------------------------------+
       Consumed Subscriptions
    +-------------------------------------------+
    Subscription Name: Awesome OS for x86_64
    Provides:          Awesome OS for x86_64 Bits
    SKU:               awesomeos-x86_64
    Contract:          3
    Account:           12331131231
    Serial:            2562182767604893603
    Pool ID:           8ac6a3a241d9a9fe0141d9aabd060f81
    Active:            True
    Quantity Used:     1
    Service Level:    
    Service Type:      
    Status Details:    Only covers 1 of 2 sockets.
    Starts:            10/21/2013
    Ends:              10/21/2014
    System Type:       Physical
     
    Subscription Name: Awesome OS for x86_64
    Provides:          Awesome OS for x86_64 Bits
    SKU:               awesomeos-x86_64
    Contract:          3
    Account:           12331131231
    Serial:            338637611748851585
    Pool ID:           8ac6a3a241d9a9fe0141d9aabb280ec0
    Active:            False
    Quantity Used:     1
    Service Level:    
    Service Type:      
    Status Details:    
    Starts:            10/11/2014
    Ends:              10/11/2015
    System Type:       Physical
     
    [root@localhost ~]# subscription-manager status --ondate 2014-10-11
    +-------------------------------------------+
       System Status Details
    +-------------------------------------------+
    Overall Status: Insufficient
     
    Awesome OS for x86_64:
    - Only covers 1 of 2 sockets.
     
    [root@localhost ~]# tail -f /var/log/rhsm/rhsm.log
    2013-10-21 18:16:46,117 [DEBUG] subscription-manager @certdirectory.py:204 - Installed product IDs: ['100000000000002']
    2013-10-21 18:16:46,117 [DEBUG] subscription-manager @connection.py:441 - Making request: GET /candlepin/consumers/fdf74286-f5ea-4d50-9ec1-ef053567cd7e/compliance?on_date=2014-10-11T00%3A00%3A00
    2013-10-21 18:16:46,180 [DEBUG] subscription-manager @connection.py:460 - Response status: 200
    2013-10-21 18:16:46,183 [DEBUG] subscription-manager @cert_sorter.py:200 - valid entitled products: []
    2013-10-21 18:16:46,184 [DEBUG] subscription-manager @cert_sorter.py:201 - expired entitled products: []
    2013-10-21 18:16:46,184 [DEBUG] subscription-manager @cert_sorter.py:202 - partially entitled products: ['100000000000002']
    2013-10-21 18:16:46,184 [DEBUG] subscription-manager @cert_sorter.py:203 - unentitled products: []
    2013-10-21 18:16:46,184 [DEBUG] subscription-manager @cert_sorter.py:204 - future products: []
    2013-10-21 18:16:46,184 [DEBUG] subscription-manager @cert_sorter.py:205 - partial stacks: ['1']
    2013-10-21 18:16:46,184 [DEBUG] subscription-manager @cert_sorter.py:206 - entitlements valid until: 2014-10-10 18:30:00+00:00


Actual results:


Expected results:
Should display the system status for date 2014-10-11 which should current

Additional info:

Comment 2 Carter Kozak 2013-10-22 12:39:22 UTC
This does not appear to be a bug.  The subscription that you've attached does not start at midnight on the morning of 10-11-2014.  If you list --available with 10-11-2014, that subscription will not be displayed, because it hasn't started at by midnight, so the behavior of list --available --ondate and status --ondate match.

Let me know if there's any additional info you need, or if I'm missing something.

Comment 3 Devan Goodwin 2014-09-16 12:37:00 UTC
Shwetha raised some more concerns about this but we think we know what's going on.

With client and server in IST (GMT + 5.5 hours), asking for status on CLI with --ondate you specify JUST a date, no timestamp or timezone.

We believe the server interprets this as 00:00 in the system's timezone, GMT +5.5 hours.

If the subscription's start date is 2015-09-05 00:00 GMT, asking for status at 00:00 GMT + 5.5 results in the subscription not actually being active yet, so it is *correctly* not considered.

This is just a fact of life if we intend to show just dates, and input just dates without full timestamp + timezone. This was done for user experience but the side effect is that things can get weird if you're trying to ask for status directly on the start date, and your subscription start date is not exactly midnight in your specific timezone, which is actually quite unlikely.

There may be a case to be made to always show exact start/end dates, and even if we only want users to input dates, we could use the output to show that we converted it to their timezone.

Likely not something we should rock the boat on right now but it is a potential discussion to have.