[Openstack] Downstream handling of extensions

Glen Campbell glen.campbell at RACKSPACE.COM
Thu Jun 14 18:09:00 UTC 2012


Oops, realized that I didn't include the list…

Glen Campbell • Developer Relations Group
glen.campbell at rackspace.com<mailto:glen.campbell at rackspace.com> • (210) 446-9990 • @glenc


On Jun 14, 2012, at 12:26 PM, Brian Waldon wrote:

My team is working on a set of language bindings for OpenStack and Rackspace services. The first language we're working on is Python, and I'm trying to come up with a simple, generic way to handle API extensions.

The first question that comes to mind is why duplicate effort with the rest of the community? We already have a comprehensive set of python bindings and would love to have some real development effort invested in them.


Two reasons:

1. Because there's existing bindings :) None of us are very strong Python developers, and it gives us a chance to get through the existing code and learn from the pros
2. Because there's only existing bindings for OpenStack stuff; not for (Rackspace-specific services) CloudDns, CloudDatabases, etc.

We also have as our goal solving some of the larger problems (such as generic extension handling). We hope to address those and feed them back to the community. For example, the novaclient only supports native Keystone and RAX-KSKEY auth. It doesn't support any of the other auth extensions out there, and it's hard-coded to look at only those two. If I develope a generic auth module, we could update novaclient and voila! it would support HP's slightly different API key mechanism plus others that come along.

So, for the OpenStack projects, you can think of this as the "real development effort" invested in them, since they're our sole focus at the moment.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120614/466207f9/attachment.html>


More information about the Openstack mailing list