Thanks Tim and Monty! I also agree with ( c ). Here’s a simple patch doing that: https://review.openstack.org/#/c/424385/
From: Tim Hinrichs <t...@styra.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Monday, January 23, 2017 at 7:55 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [congress] ocata client causes feature regression with pre-ocata server > 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://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
__________________________________________________________________________ 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
