
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div>Hi Tim,</div><div>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.</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Tim Hinrichs <<a href="mailto:tim@styra.com">tim@styra.com</a>><br><span style="font-weight:bold">Date: </span> Saturday, January 21, 2017 at 2:33 PM<br><span style="font-weight:bold">To: </span> Eric Kao <<a href="mailto:ekcs.openstack@gmail.com">ekcs.openstack@gmail.com</a>>, "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [congress] ocata client causes feature regression with pre-ocata server<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">How about we go into the preocata server and change requirements.txt to ensure it only supports the older clients. Something like...<br><br>Python-congressclient>2.3<2.5 <br><br>Or whatever the versions are. <br><br>Tim<br><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 20, 2017 at 7:07 PM Eric K <<a href="mailto:ekcs.openstack@gmail.com">ekcs.openstack@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class="gmail_msg"><br class="gmail_msg">

I was getting ready to request release of congress client, but I<br class="gmail_msg">

remembered that the new client causes feature regression if used with<br class="gmail_msg">

older versions of congress. Specifically, new client with pre-Ocata<br class="gmail_msg">

congress cannot refer to datasource by name, something that could be done<br class="gmail_msg">

with pre-Ocata client.<br class="gmail_msg"><br class="gmail_msg">

Here¹s the patch of interest: <a href="https://review.openstack.org/#/c/407329/" rel="noreferrer" class="gmail_msg" target="_blank">https://review.openstack.org/#/c/407329/</a><br class="gmail_msg">

<<a href="https://review.openstack.org/#/c/407329/4" rel="noreferrer" class="gmail_msg" target="_blank">https://review.openstack.org/#/c/407329/4</a>><br class="gmail_msg"><br class="gmail_msg">

A few questions:<br class="gmail_msg"><br class="gmail_msg">

Are we okay with the regression? Seems like it could cause a fair bit of<br class="gmail_msg">

annoyance for users.<br class="gmail_msg">

   1. If we¹re okay with that, what¹s the best way to document that<br class="gmail_msg">

pre-Ocata congress should be used with pre-Ocata client?<br class="gmail_msg">

   2. If not, how we avoid the regression? Here are some candidates I can<br class="gmail_msg">

think of.<br class="gmail_msg">

          a. Client detects congress version and act accordingly. I don¹t<br class="gmail_msg">

think this is possible, nor desirable for client to be concerned with<br class="gmail_msg">

congress version not just API version.<br class="gmail_msg">

          b. Release backward compatible API version 1.1 that supports<br class="gmail_msg">

getting datasource by name_or_id. Then client will take different paths<br class="gmail_msg">

depending on API version.<br class="gmail_msg">

          c. If datasource not found, client falls back on old method of<br class="gmail_msg">

retrieving list of datasources to resolve name into UUID. This would work,<br class="gmail_msg">

but causes extra API & DB call in many cases.<br class="gmail_msg">

          d. Patch old versions of Congress to support getting datasource<br class="gmail_msg">

by name_or_id. Essentially, it was always a bug that the API didn¹t<br class="gmail_msg">

support name_or_id.<br class="gmail_msg"><br class="gmail_msg">

Thanks!<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"></blockquote></div></blockquote></span></body></html>