Rackspace’s Pyrax not ready for prime time

An update to an earlier post…

We’ve had problems using the pyrax SDK, mostly in account authentication.

First, it wasn’t at all clear when, or under what conditions, we had to re-authenticate our pyrax token. As documented, after you initially authenticate your credentials, pyrax handles all subsequent re-authentication under the covers. I.e., it will automatically re-authenticate the token if it ever expires.

This is kind of odd. I don’t understand why a good token should need re-authentication.

We then discovered that pyrax sometimes can’t re-authenticate our token! Every 19 hours, we hit a period of about five hours when our token won’t automatically authenticate. Why? I still don’t have a clear answer. Some authentication server, somewhere, clearly gets confused. You won’t run into this bug if you don’t have long-running processes. But, we do.

I tried to work around this bug by having our processes always use a fresh token. So every time we want to do a CloudFiles operation, we call pyrax.clear_credentials(), then re-authenticate. Even when this shouldn’t be necessary. But that doesn’t always work, either. Why not? I don’t know but I’m trying to find out.

There are other small irritations. The on-line documentation is organized and formatted for C++ code, which makes for unpleasant reading. And magnificent function parameters like return_none = False.

The nature of these problems means it’ll take some time to figure them out. They aren’t as easy to debug as when a function always throws an exception when given a particular argument.

If you’re contemplating migrating to pyrax, I suggest you wait six months. It needs to bake in the oven a little longer.