I agree with all of your points. Having to maintain a client library wasn't on our list of "fun things to do".
The only thing I can see in Jacobian's python-openstack.compute branch that differs from his old Rackspace API library is the addition of the auth URL and a rebranding. We added that functionality to his old project last year, issued a pull request and were ignored. Perhaps his stance on working with us has changed since? Moreover, since that first pull request we've really moved on with the project and there is much more functionality in the library: - the new zone capabilities - api versioning - new OS 1.1 features - better error handling and reporting - better debugging That said, the more we deal with the library the more we realize we should re-evaluate its use. It's a very chatty implementation ... frequently round-tripping to the server to fetch more detailed information. This is fine for a CLI, but as an internal library too inefficient. Rather than merging these two efforts perhaps we should consider a new tack? https://github.com/jacobian/openstack.compute https://github.com/rackspace/python-novaclient -S ________________________________________ From: openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net] on behalf of Soren Hansen [so...@linux2go.dk] Sent: Wednesday, May 18, 2011 3:17 AM To: openstack@lists.launchpad.net Subject: [Openstack] python-novaclient vs. python-openstack.compute python-novaclient[0] is the client for Nova that we maintain ourselves. It is a fork of jacobian's python-cloudservers. python-openstack.compute is jacobian's new branch of python-cloudservers. I wonder if there's any point in having two distinct, but very similar libraries to do same thing. If not, how do we move forward? Yielding to jacobian (or someone else external to the project) helps keep us honest, since someone outside the project would look at the API docs to extend their client tools, and will hopefully point out if there's divergence between the API docs and the actual exposed API. However, we need client tools to exercise new features exposed in the API, so I'm not sure we can reasonably live without a set of tools that we maintain ourselves to expose all the new functionality. Thoughts? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
