[openstack-dev] a "common" client library

Robert Collins robertc at robertcollins.net
Sat Jan 18 06:02:03 UTC 2014

On 17 January 2014 06:57, Mark Washenberger
<mark.washenberger at markwash.net> wrote:

> Just throwing this out there because it seems relevant to client design.
> As we've been looking at porting clients to using v2 of the Images API, its
> seems more and more to me that including the *server* version in the main
> import path is a real obstacle.
> IMO any future client libs should write library interfaces based on the
> peculiarities of user needs, not based on the vagaries of the server
> version. So as a user of this library I would do something like:
>   1 from openstack.api import images
>   2 client = images.make_me_a_client(auth_url, etcetera) # all version
> negotiation is happening here
>   3 client.list_images()  # works more or less same no matter who I'm
> talking to
> Now, there would still likely be hidden implementation code that is
> different per server version and which is instantiated in line 2 above, and
> maybe that's the library path stuff you are talking about.

That design seems guaranteed to behave somewhat poorly (e.g. fail to
upgrade) when servers are upgraded - for short lived processes like
'nova boot' that doesn't matter, but for software running in a daemon
- e.g. in nova-api talking to neutron - that seems much more likely to
be a problem.

I think the pseudo code is fine, but client shouldn't be a concrete
version locked client, rather a proxy object that can revalidate the
version every {sensible time period} and/or observe HTTP headers to
detect when upgrades are possible (or downgrades are required).


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the OpenStack-dev mailing list