On 17 January 2014 06:57, Mark Washenberger <mark.washenber...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev