launchpad-service-status can't compare datetime.datetime to NoneType

Bug #988312 reported by Peter Petrakis
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python-launchpadlib-toolkit (Ubuntu)
Fix Released
High
Unassigned
Precise
Fix Released
High
Unassigned
Quantal
Fix Released
High
Unassigned

Bug Description

[Impact]
The launchpad-service-status script indicates whether or not Launchpad is available.
lpltk clients use this tool to determine whether they will fail if they attempt to run.

One of the things the tool does to achieve this is to check the Launchpad blog for planned outages. However, if there are no planned outages listed in the feed, the tool fails due to undefined values.

[Development Fix]
The 2.x development series includes a fix that checks the results of the blog screenscraping before attempting to use it. This 2.0 branch is uploaded to quantal.

[Stable Fix]
The same fix applies on the 1.x stable series, which is being proposed for precise.

Note that with this change we're bumping the number from 0.5 to 1.0, to indicate the package is now released and considered stable. See package changelog for other changes (mainly fixes to unreported bugs) included in this release.

[Test Case]
1. Install package
2. launchpad-service-status

Broken Behavior:
$ launchpad-service-status
Traceback (most recent call last):
  File "/usr/local/bin/launchpad-service-status", line 50, in <module>
    if datetime.now() > outage_start and datetime.now() < outage_end:
TypeError: can't compare datetime.datetime to NoneType

Fixed Behavior:
$ ./scripts/launchpad-service-status
UP READWRITE

[Regression Potential]
This particular change just adds a check for None values before using them, it's unlikely to cause a regression.

There are some other changes included in 1.0, all of which are believed safe but the quantity of code changed means regressions are always possible. I feel this is a negligible risk though, because two of the bug fixes included in 1.0 address API changes in Launchpad that occurred a few months ago, and scripts written using the current (0.5) lpltk simply won't work.

As per UDS decisions, we're trying to shift into a more normal release process. However to date, most users of lpltk that I'm aware of install and run from bzr due to problems such as those mentioned above. We're hoping by being more aggressive at getting those kinds of fixes through SRU, we can gain better maintenance updates going so people don't need to run from bzr. So although this release contains some extra changes, I think they're needed, and going forward we're going to be more cherrypicky.

[Original Report]
/usr/bin/launchpad-service-status
Traceback (most recent call last):
  File "/usr/bin/launchpad-service-status", line 50, in <module>
    if datetime.now() > outage_start and datetime.now() < outage_end:
TypeError: can't compare datetime.datetime to NoneType

A quick look at the code shows that this tool is based on screen scrapping
the launchpad notification feed

http://blog.launchpad.net/category/notifications/feed

and is coming up empty.

Bryce Harrington (bryce)
description: updated
description: updated
Changed in python-launchpadlib-toolkit (Ubuntu Quantal):
status: New → Fix Released
importance: Undecided → High
Changed in python-launchpadlib-toolkit (Ubuntu Precise):
importance: Undecided → High
status: New → Fix Committed
Revision history for this message
Chris Halse Rogers (raof) wrote :

The python-launchpadlib-toolkit upload in the queue contains significant changes not mentioned in the changelog - the addition of a fix_time function, among other things.

If those are intended please reupload with an expanded changelog, or if not please upload without those changes.

Also, the diff contains the removal of the build tree which was apparently included in the previous upload. That's annoying but I won't reject it for that.

Bryce Harrington (bryce)
description: updated
Revision history for this message
Bryce Harrington (bryce) wrote :

Ah, didn't realize that 0.5 didn't already include all these changes. Yes they're all quite necessary. In fact the fix_time() function is so critical that the current 0.5 release included in precise probably doesn't work at all. It's a fix for an unannounced Launchpad API change that hit us a few months back. There is some cleanup included which is unnecessary of course but corrects some rather stupidly lazy packaging work on my part.

I've updated the changelog to itemize all the changes. Mostly everything is to fix problems people have run into, although there's also a new script and a couple new routines added; all quite safe but if they bug you I can revert them, they're not critical. To date most people have been running lpltk from bzr, so we don't have bug reports on the problems - we would just fix bzr and users would re-pull. We're planning to change to a more formal model with releases and tests and actual version numbers going forward. If we can get this SRU in we can baseline this from precise; if not, we'll just rein things back in and wait for quantal.

Due to the cleanup cruft you might find it easier to review the changes via the bzr log, which can be obtained via:
  https://code.launchpad.net/~arsenal-devel/lpltk/1.x
Revision 139 should match the 0.5 release included in precise currently.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Hi Bryce. Since the change is so significant, is there any regression test plan for testing the library? The test case listed here is great for this bug, but there are so many other things fixed, it makes me nervous to just update all of those things to fix this bug, without some kind of broader testing plan.

Another option is to figure out the actual impact of not updating this. It sounds to me like you're thinking perhaps python-launchpadlib-toolkit prior to 1.0 just won't work at all. If you can show some evidence of that, then I think users are most likely going to need this update no matter what and we should push it through.

Revision history for this message
Bryce Harrington (bryce) wrote :

The impact is just that we'd have folks continue installing and running the bzr lpltk rather than the one from Ubuntu. Like I said that's what people are doing currently due to those bugs so not really an humongous impact for them, really it's just a pain point for new users.

Regarding a broad test suite, unfortunately the tests in this version of lpltk are in rather poor shape; there's only half a dozen and don't give full coverage of the codebase.

Revision history for this message
Chris Halse Rogers (raof) wrote :

I'm prepared to believe that the package is not useful in its current state; this is a low-impact package, so we can afford to be more aggressive. Accepting into proposed.

tags: added: verification-needed
Revision history for this message
Chris Halse Rogers (raof) wrote : Please test proposed package

Hello Peter, or anyone else affected,

Accepted python-launchpadlib-toolkit into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Revision history for this message
Sebastien Bacher (seb128) wrote :

I've tested the precise version and it's buggy indeed, then installed the proposed version and confirmed that it resolves the issue

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-launchpadlib-toolkit - 1.0

---------------
python-launchpadlib-toolkit (1.0) precise-proposed; urgency=low

  * launchpad-service-status: Backport fix from lpltk 2.x (commit #149) to
    check blog screenscrape results. This tool determines if there is a
    launchpad outage by examining the launchpad blog at
    http://blog.launchpad.net/category/notifications/feed. It can happen
    there are no outages listed, in which case outage_start and outage_end
    will be undefined. Don't attempt to test against these parameters if
    this is the case.
    (LP: #988312)
  * Fix breakage caused by change in wadllib's date handling. In the past
    launchpadlib would return actual date objects but now it returns unicode
    timestamps. Add fix_time() routine to work around this problem.
    Otherwise all lpltk-using scripts will fail to run. Idemptontly, provide
    functionality in o2str to convert real datetimes into timestamps.
  * Fix breakage caused by Launchpad not providing __len__ any more. This
    was dropped by Launchpad to resolve some timeout issues they were
    having. Length counts are now provided by dedicated properties.
    Switch to using them.
  * Fix inclusion of missing 'iso-tracker' tag in gravity calculation.
  * Add to_dict() routines to bug and bug_task to help for generating JSON.
  * Add team functionality for determining subbed packages and parent team.
  * New script for searching inside attachments of a package's bugs.
  * Cleanup a stray build/ directory.
  * Add some tests.
  * setup.py, debian/control: Define package pre-requisites.
  * Increment version number to 1.0 (stable release), as per UDS-Q session
    decision. All changes on the 1.x branch will be stable bug fixes
    henceforth.
 -- Bryce Harrington <email address hidden> Fri, 18 May 2012 12:22:04 -0700

Changed in python-launchpadlib-toolkit (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.