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

[Eric K]

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

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

[Tim Hinrichs]

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

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

[Monty Taylor]

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

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

[Eric K]

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 
Date:  Saturday, January 21, 2017 at 2:33 PM
To:  Eric Kao , "OpenStack Development Mailing
List (not for usage questions)" 
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  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/
>> 
>> 
>> 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!
>> 
>> 


__
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

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

[Tim Hinrichs]

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  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/
> 
>
> 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!
>
>
>
__
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-dev] [congress] ocata client causes feature regression with pre-ocata server

[Eric K]

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/


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!



__
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