Hey Sandy, So the API version works in the sense that if you hit /v1.0 you'll get the older v1.0 style API. Likewise for /v1.1.
The big things still in flux as far as v1.1 support in nova: -making the JSON and XML serialization match the spec. On the JSON side there are some "collections" changes that need making. On the XML side I'm not sure we always adhere to the SPEC. -ID and HREFs (the ability to specify a custom glance image HREF when creating an instance). The implementation for this in cactus just chopped of the image ID from the URL and used that as the image_id for the image service. --- When updating a v1.0 binding to v1.1 you'll have to look at changes in metadata, new image metadata support, and some things moved around (change password moved from an update to an action), extensions, etc. --- I wouldn't be opposed to maintaining bindings outside of the project. Like Soren points out it does keep us honest. The downside of this is the bindings probably won't have any niche features and may lag new features a bit. I see external bindings as being more end user friendly and as such you may have a hard time getting features we add for administrative API's implemented (zones, users, etc.). In Ruby land... We have started bumping the Openstack Compute Ruby bindings to support v1.1 features. There is a branch in the works here: lp:~ironcamel/ruby-openstack-compute/v11 which takes care of most of the metadata changes, ID's and HREFs, formats, etc. We weren't planning on pushing the new Ruby gem with v1.1 support until the serialization stuff finally settles down. Hope this helps. Dan -----Original Message----- From: "Sandy Walsh" <sandy.wa...@rackspace.com> Sent: Wednesday, May 18, 2011 8:20am To: "Soren Hansen" <so...@linux2go.dk>, "openstack@lists.launchpad.net" <openstack@lists.launchpad.net> Subject: Re: [Openstack] python-novaclient vs. python-openstack.compute Whoops, I could be mistaken on the "new 1.1 features" part of that email. Versioning is in a pending pull request. I'd like to hear from the Titan team on their plans ... especially around 1.1 support. And, dare I say it, making the client library data-driven so it will change whenever the server-side API changes would be ideal. Right now it's a pita to have to update the client library every time something on the server changes. This also brings us back to the discussion of whether novaclient (or something) should be in the nova source tree and not separate. -S ________________________________________ From: Sandy Walsh Sent: Wednesday, May 18, 2011 9:07 AM To: Soren Hansen; openstack@lists.launchpad.net Subject: RE: [Openstack] 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....@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
