<div dir="ltr"><div>Hi Devananda,</div><div><br></div><div>Thanks for bringing this up. I've seen some recent discussions about changing our python-client so that it supports a range of versions of the server. I think that makes sense and that's how/where we can fix the client so that it supports requests/responses that are particular to a version. (The trick is to do it so that the code doesn't become unwieldy.)</div><div><br></div><div>Our client has been "broken" since probably day 11:-), so I don't think it makes sense to have newer clients properly support Ironic servers prior to when microversioning was added. It would be great to have, but I am not sure the amount of effort to do that is warranted, given everything else on our plate.</div><div><br></div><div>--ruby</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 March 2015 at 19:12, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
Recently, I've been thinking more of how users of our python client<br>
will interact with the service, and in particular, how they might<br>
expect different instances of Ironic to behave.<br>
<br>
We added several extensions to the API this cycle, and along with<br>
that, also landed microversion support (I'll say more on that in<br>
another thread). However, I don't feel like we've collectively given<br>
nearly enough thought to the python client. It seems to work well<br>
enough for our CI testing, but is that really enough? What about user<br>
experience?<br>
<br>
In my own testing of the client versioning patch that landed on<br>
Friday, I noticed some pretty appalling errors (some unrelated to that<br>
patch) when pointing the current client at a server running the<br>
stable/juno code...<br>
<br>
<a href="http://paste.openstack.org/show/u91DtCf0fwRyv0auQWpx/" target="_blank">http://paste.openstack.org/show/u91DtCf0fwRyv0auQWpx/</a><br>
<br>
<br>
I haven't filed specific bugs from yet this because I think the issue<br>
is large enough that we should talk about a plan first. I think that<br>
starts by agreeing on who the intended audience is and what level of<br>
forward-and-backward compatibility we are going to commit to [*],<br>
documenting that agreement, and then come up with a plan to deliver<br>
that during the L cycle. I'd like to start the discussion now, so I<br>
have put it on the agenda for Monday, but I also expect it will be a<br>
topic at the Vancouver summit.<br>
<br>
-Devananda<br>
<br>
<br>
[*] full disclosure<br>
<br>
I believe we have to commit to building a client that works well with<br>
every release since Icehouse, and the changes we've introduced in the<br>
client in this cycle do not.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>