At some point the client sometimes made multiple API calls. I think (c) seems right too.
Tim On Sun, Jan 22, 2017 at 1:15 AM Monty Taylor <mord...@inaugust.com> wrote: > 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 > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
