openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #02436
Re: python-novaclient vs. python-openstack.compute
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.com@xxxxxxxxxxxxxxxxxxx [openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of Soren Hansen [soren@xxxxxxxxxxx]
Sent: Wednesday, May 18, 2011 3:17 AM
To: openstack@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
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 abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.
References