Keystone/Keystoneclient CMS routines fail on first run on Python 2.6

[Dirk Mueller]

Python 2.6 can raise OSError when too much data is
written to STDIN and the process died prematurely.

In the case of keystoneclient this happens during
the first cms_verify() call of a process. The calling
logic expects a useful error message in order to
refetches CA or singing CERT, which is missing in the
case of an OSError. There is no way to capture the
original error message of openssl, so the only
way to let the outer logic continue is to fake one
error message instead.

[Dolph Mathews (dolph)]

Can you link the review here? I'm pretty sure I've seen it, but I wasn't able to find it in gerrit today. Thanks!

[Dirk Mueller (dmllr)]

https://review.openstack.org/#/c/33851/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/33851
Committed: http://github.com/openstack/python-keystoneclient/commit/07a7c3102c684baa8b364f419c9e9b6c18360f5e
Submitter: Jenkins
Branch: master

commit 07a7c3102c684baa8b364f419c9e9b6c18360f5e
Author: Dirk Mueller <email address hidden>
Date: Thu Jun 20 18:49:26 2013 +0200

    Add workaround for OSError raised by Popen.communicate()

    Python 2.6 can raise OSError when too much data is
    written to STDIN and the process died prematurely.

    In the case of keystoneclient this happens during
    the first cms_verify() call of a process. The calling
    logic expects a useful error message in order to
    refetch the CA or singing CERT, which is missing in the
    case of an OSError. So just fake it instead.

    Add basic unit tests to cover all of the public methods from
    keystone.common.cms, raising test coverage to 77%. Add
    unit test for this specific bug (test_cms_verify_token_no_oserror).

    Closes-Bug: LP Bug#1235252

    Change-Id: I6e650ab9494c605b4e41c78c87a9505e09d5fc29