Open Stack

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 <tim at styra.com>
Date:  Saturday, January 21, 2017 at 2:33 PM
To:  Eric Kao <ekcs.openstack at gmail.com>, "OpenStack Development Mailing
List (not for usage questions)" <openstack-dev at 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.openstack at 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!
>> 
>> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170121/ef6e77dd/attachment.html>