[openstack-dev] [congress] ocata client causes feature regression with pre-ocata server

Monty Taylor mordred at inaugust.com
Sun Jan 22 09:13:19 UTC 2017


On 01/21/2017 04:07 AM, Eric K 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.

This is right. New client lib should always continue to work with old
server. (A user should be able to just pip install python-congressclient
and have it work regardless of when their operator decides to upgrade or
not upgrade their cloud)

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

I'm a fan of d - but I don't believe it will help - since the problem
will still manifest for users who do not have control over the server
installation.

I'd suggest c is the most robust. It _is_ potentially more expensive -
but that's a good motivation for the deployer to upgrade their
installation of congress without negatively impacting the consumer in
the  meantime.

Monty



More information about the OpenStack-dev mailing list