Hide Forgot
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:
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.
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.