This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1262435 - available service levels from subscription pools that have expired are not getting purged
available service levels from subscription pools that have expired are not ge...
Status: CLOSED NOTABUG
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
1.2
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Filip Nguyen
Katello QA List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-11 12:25 EDT by John Sefler
Modified: 2015-09-14 10:21 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-14 10:21:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Sefler 2015-09-11 12:25:06 EDT
Description of problem:
I have an automated test that was designed for candlepin < 2.0 that depended on a candlepin call to refresh pools in order to eliminate available service levels from a pool that has expired.  Now in candlepin 2.0, the refresh pools api is a no-op.  As such, service levels from expired pools remain available for some undertermined amount of time.  I'm not sure how to handle this.

Nore: the date on my subscription-manager client and onpremise candlepin server are exactly in sync.


Version-Release number of selected component (if applicable):
[root@jsefler-7 ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 2.0.6-1
subscription management rules: 5.16
subscription-manager: 1.15.9-7.el7
python-rhsm: 1.15.4-4.el7


How reproducible:


Steps to Reproduce:
Prior to running these steps on a subscription-manager client, I have created a subscription pool that is about to expire in 1 minute from now.  Here's what the subscription-manager client sees in 1 minute increments...


[root@jsefler-7 ~]#  subscription-manager register --org=admin --username=testuser1
Password: 
Registering to: jsefler-f22-candlepin.usersys.redhat.com:8443/candlepin
The system has been registered with ID: dec18665-cc25-43a1-83c8-03b8da6859f3 
[root@jsefler-7 ~]# 
[root@jsefler-7 ~]# date; subscription-manager service-level --list; subscription-manager list --available --matches "Expired SLA"; sleep 60;
Fri Sep 11 11:59:30 EDT 2015
+-------------------------------------------+
               Available Service Levels
+-------------------------------------------+
Expired SLA
Full-Service
Generic SLA
None
Premium
Standard
Super
+-------------------------------------------+
    Available Subscriptions
+-------------------------------------------+
Subscription Name:   An "Expired SLA" service level subscription
Provides:            
SKU:                 expired-sla-product-sku
Contract:            435923461
Pool ID:             8a9087904f665093014fbd21a3722cfd
Provides Management: No
Available:           4
Suggested:           1
Service Level:       Expired SLA
Service Type:        
Subscription Type:   Standard
Ends:                09/11/2015
System Type:         Physical

[root@jsefler-7 ~]# date; subscription-manager service-level --list; subscription-manager list --available --matches "Expired SLA"; sleep 60;
Fri Sep 11 12:00:36 EDT 2015
+-------------------------------------------+
               Available Service Levels
+-------------------------------------------+
Expired SLA
Full-Service
Generic SLA
None
Premium
Standard
Super
No available subscription pools were found matching the expression "Expired SLA".
[root@jsefler-7 ~]# date; subscription-manager service-level --list; subscription-manager list --available --matches "Expired SLA"; sleep 60;
Fri Sep 11 12:01:42 EDT 2015
+-------------------------------------------+
               Available Service Levels
+-------------------------------------------+
Expired SLA
Full-Service
Generic SLA
None
Premium
Standard
Super
No available subscription pools were found matching the expression "Expired SLA".
[root@jsefler-7 ~]# date; subscription-manager service-level --list; subscription-manager list --available --matches "Expired SLA"; sleep 60;
Fri Sep 11 12:03:03 EDT 2015
+-------------------------------------------+
               Available Service Levels
+-------------------------------------------+
Expired SLA
Full-Service
Generic SLA
None
Premium
Standard
Super
No available subscription pools were found matching the expression "Expired SLA".




Actual results:
One minute prior to the expiration of the pool, the "Expired SLA" service level is shown as available and there is indeed a subscription with the "Expired SLA"
available for consumption.

One minute later, the "Expired SLA" service level continues to be shown as available despite the fact that the list of available pools no longer contains a pool with an "Expired SLA" service level.

Even many minutes later the "Expired SLA" service level continues to be shown as available. when it is not.


Additional Info:

Prior to Candlepin 2.0, a candlpin API call to refresh the pools would clean the available expired service level.
Comment 1 Filip Nguyen 2015-09-14 07:49:37 EDT
John, I see the same behaviour as you do. 

What is happening on the server;
 1) Your subscription "An Expired SLA service level subscription expires" expires
 2) From now on, you won't be able to see it in the list of "list --available --matches ...". 
 3) We run ExpiredPoolsJob every hour that is deleting expired subs.
 4) After no more than an hour your expired subscription will be deleted
 5) Now you may not see the Service level in "service-level --list"


Do you expect that service-level --list only returns those Service Levels that are currently available for some available pool? The current logic for "service-level --list" lists even those service levels that are not yet available (e.g. those that will be active in the future, and possibly some others as well). The consequence of this is that you may still see the service level in step 5) even after an hour.

Do you still think this is a bug?
Comment 2 Filip Nguyen 2015-09-14 07:55:23 EDT
And to answer your questions. What can be done (via configuration of CP server) is shortening the interval when ExpiredPoolsJob to e.g. 1 minute.
Comment 3 Filip Nguyen 2015-09-14 08:29:14 EDT
To run ExpiredPoolsJob every minute use the following configuration:

/etc/candlepin/candlepin.conf:
pinsetter.org.candlepin.pinsetter.tasks.ExpiredPoolsJob.schedule=0 * * * * ?
Comment 4 John Sefler 2015-09-14 10:21:41 EDT
Thank you Filip for investigating and proposing a workaround for testing against candlepin-2.0.

Based on your investigation, candlepin appears to be working properly.

Moving this bug to CLOSED NOTABUG

Note You need to log in before you can comment on or make changes to this bug.