openstack team mailing list archive

["Dan Prince" <dan.prince@xxxxxxxxxxxxx>]

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.walsh@xxxxxxxxxxxxx>
Sent: Wednesday, May 18, 2011 8:20am
To: "Soren Hansen" <soren@xxxxxxxxxxx>, "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
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.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.


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp