Hmmm looks like a bug in CP or RHSM because Katello is proxying this request. My candlepin returned this:


Sep 13 12:13:33 [http-8443-1] DEBUG org.fedoraproject.candlepin.servlet.filter.logging.LoggingFilter - 
====Response====
  Status: 200
  Content-type: application/json
====Response====
Sep 13 12:13:33 [http-8443-1] DEBUG org.fedoraproject.candlepin.servlet.filter.logging.LoggingFilter - ====ResponseBody====
Sep 13 12:13:33 [http-8443-1] DEBUG org.fedoraproject.candlepin.servlet.filter.logging.LoggingFilter - [{"id":"ff8080813261df3b013261dfc8950004","attributes":[],"owner":{"href":"/owners/ACME_Corporation","id":"ff8080813261df3b013261df64290001","key":"ACME_Corporation","displayName":"ACME_Corporation"},"providedProducts":[],"endDate":"2041-09-05T00:00:00.000+0000","startDate":"2011-09-13T00:00:00.000+0000","productName":"ypd_c0543","contractNumber":"","accountNumber":"","quantity":-1,"productId":"1315902047576","subscriptionId":"ff8080813261df3b013261dfc6090003","consumed":0,"sourceEntitlement":null,"href":"/pools/ff8080813261df3b013261dfc8950004","activeSubscription":true,"restrictedToUsername":null,"productAttributes":[],"updated":"2011-09-13T08:20:48.405+0000","created":"2011-09-13T08:20:48.405+0000"}]

Reformatted:

{
  "id": "ff8080813261df3b013261dfc8950004",
  "attributes": [

  ],
  "owner": {
    "href": "/owners/ACME_Corporation",
    "id": "ff8080813261df3b013261df64290001",
    "key": "ACME_Corporation",
    "displayName": "ACME_Corporation"
  },
  "providedProducts": [

  ],
  "endDate": "2041-09-05T00:00:00.000+0000",
  "startDate": "2011-09-13T00:00:00.000+0000",
  "productName": "ypd_c0543",
  "contractNumber": "",
  "accountNumber": "",
  "quantity": -1,
  "productId": "1315902047576",
  "subscriptionId": "ff8080813261df3b013261dfc6090003",
  "consumed": 0,
  "sourceEntitlement": null,
  "href": "/pools/ff8080813261df3b013261dfc8950004",
  "activeSubscription": true,
  "restrictedToUsername": null,
  "productAttributes": [

  ],
  "updated": "2011-09-13T08:20:48.405+0000",
  "created": "2011-09-13T08:20:48.405+0000"
}

as the line in rhsm is this one (managerlib.py:444):

        d['endDate'] = formatDate(parseDate(d['endDate']))

I guess the issue is with the endDate value "2041-09-05T00:00:00.000+0000"

Btw this is the import file I had when I saw this error:

http://git.fedorahosted.org/git/?p=katello.git;a=tree;f=cli/test-system;h=960a0662682b4c284b2e39d44c263f06255e018b;hb=HEAD

(see the zip file). Changing product to "Entitlements", this is not Katello issue probably.

BLOCKER for Katello. Could you guys look on it please? Thanks!

The import.zip file in the git link above does not appear to be involved, this loads fine in candlepin and subscription-manager can list --available without issues. It also does not seem to contain anything which expires in 2041.

lzap believes the subscription in question is a yum product defined in katello. The subscription json going to the client looks like:

Sending GET request to Candlepin: /owners/org_rhsm_3e66d7/pools?consumer=c11c1e9b-52de-46c3-8ec5-4a9e7a407290&listall=true
[{"id":"ff80808132675a060132688502eb0181","attributes":[],"owner":{"href":"/owners/org_rhsm_3e66d7","id":"ff80808132675a0601326884daca017e","key":"org_rhsm_3e66d7","displayName":"org_rhsm_3e66d7"},"providedProducts":[],"endDate":"2041-09-06T00:00:00.000+0000","startDate":"2011-09-14T00:00:00.000+0000","productName":"yum_product_3e66d7","contractNumber":"","accountNumber":"","quantity":-1,"productId":"1316013539685","subscriptionId":"ff80808132675a060132688501f20180","consumed":0,"sourceEntitlement":null,"href":"/pools/ff80808132675a060132688502eb0181","activeSubscription":true,"restrictedToUsername":null,"productAttributes":[],"updated":"2011-09-14T15:19:00.075+0000","created":"2011-09-14T15:19:00.075+0000"}]


The endDate does seem to be the problem, but again I cannot reproduce via a test for parseDate with this value:

parseDate("2041-09-06T00:00:00.000+0000")

lzap's system is in EST+2 timezone, I've tried setting my system to this and several others and I still cannot reproduce.

Still investigating.

From the mktime docs: 

If the input value cannot be represented as a valid time, either OverflowError or ValueError will be raised (which depends on whether the invalid value is caught by Python or the underlying C libraries). The earliest date for which it can generate a time is platform-dependent.

I'm on x86_65 and can't reproduce all the way up to year 9999. Any chance this is 32-bit and a smaller year fixes the issue? (can be edited in cp_pool table in db)

Script to try and reproduce (works fine on my system):

#!/usr/bin/env python
import sys
sys.path.insert(0, '/usr/share/rhsm')
from subscription_manager.managerlib import parseDate

print parseDate("2041-09-06T00:00:00.000+0000")

Reproduced on an i686 guest, set the year to anything less than 2038 and it will work, so we are quite likely dealing with: http://en.wikipedia.org/wiki/Year_2038_problem

Question is, what can we do about it?

I am sorry I did not tell you that my client was i686.

Is there some quick fix that would unblock me for now?

Fixed in subscription-manager.git master branch: a0f3d37af5f0effba574751ec020ccac437a01c3

We're catching this overflow and instead returning a safe date in 2038. Such a system is obviously in big trouble come this date, but we can now keep them operational now if they somehow got a subscription with an date in this range.

QE: to reproduce, you would need an i686 system plus a subscription with start or end date beyond Feb 2038.

Using the script above in comment #7 however might be easier, just run on an i686 system.

Testing in version:
subscription-manager-0.99.14-1.el6.i686

[root@cypher ~]# uname -m
i686
[root@cypher ~]# cat bugtest.py 
#!/usr/bin/env python
import sys
sys.path.insert(0, '/usr/share/rhsm')
from subscription_manager.managerlib import parseDate

print parseDate("2041-09-06T00:00:00.000+0000")


[root@cypher ~]# python bugtest.py 
No handlers could be found for logger "rhsm-app.subscription_manager.managerlib"
2038-01-01 00:00:00+00:00

^^ 
This seems to take larger dates and knocks them back to the max year (exactly as described).  There are no tracebacks.

Marking Verified

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.

http://rhn.redhat.com/errata/RHBA-2012-0804.html