Open Stack

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 <tim at styra.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date:  Monday, January 23, 2017 at 7:55 AM
To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at 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 <mordred at 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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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