How about we go into the preocata server and change requirements.txt to ensure it only supports the older clients. Something like...
Python-congressclient>2.3<2.5 Or whatever the versions are. Tim On Fri, Jan 20, 2017 at 7:07 PM Eric K <ekcs.openst...@gmail.com> wrote: > Hi all, > > I was getting ready to request release of congress client, but I > remembered that the new client causes feature regression if used with > older versions of congress. Specifically, new client with pre-Ocata > congress cannot refer to datasource by name, something that could be done > with pre-Ocata client. > > Here¹s the patch of interest: https://review.openstack.org/#/c/407329/ > <https://review.openstack.org/#/c/407329/4> > > A few questions: > > Are we okay with the regression? Seems like it could cause a fair bit of > annoyance for users. > 1. If we¹re okay with that, what¹s the best way to document that > pre-Ocata congress should be used with pre-Ocata client? > 2. If not, how we avoid the regression? Here are some candidates I can > think of. > a. Client detects congress version and act accordingly. I don¹t > think this is possible, nor desirable for client to be concerned with > congress version not just API version. > b. Release backward compatible API version 1.1 that supports > getting datasource by name_or_id. Then client will take different paths > depending on API version. > c. If datasource not found, client falls back on old method of > retrieving list of datasources to resolve name into UUID. This would work, > but causes extra API & DB call in many cases. > d. Patch old versions of Congress to support getting datasource > by name_or_id. Essentially, it was always a bug that the API didn¹t > support name_or_id. > > Thanks! > > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
