Hi Tim, I thought something like that would work. But actually python-congressclient is not a listed requirement of congress server, no vice versa. Which is correct in the sense that installing and running one does not require installing the other on the same machine.
From: Tim Hinrichs <t...@styra.com> Date: Saturday, January 21, 2017 at 2:33 PM To: Eric Kao <ekcs.openst...@gmail.com>, "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [congress] ocata client causes feature regression with pre-ocata server > 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