Open Stack

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).

-Rob



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