Hi Devananda,

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.)

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.

--ruby


On 7 March 2015 at 19:12, Devananda van der Veen <devananda....@gmail.com>
wrote:

> Hi folks,
>
> Recently, I've been thinking more of how users of our python client
> will interact with the service, and in particular, how they might
> expect different instances of Ironic to behave.
>
> We added several extensions to the API this cycle, and along with
> that, also landed microversion support (I'll say more on that in
> another thread). However, I don't feel like we've collectively given
> nearly enough thought to the python client. It seems to work well
> enough for our CI testing, but is that really enough? What about user
> experience?
>
> In my own testing of the client versioning patch that landed on
> Friday, I noticed some pretty appalling errors (some unrelated to that
> patch) when pointing the current client at a server running the
> stable/juno code...
>
> http://paste.openstack.org/show/u91DtCf0fwRyv0auQWpx/
>
>
> I haven't filed specific bugs from yet this because I think the issue
> is large enough that we should talk about a plan first. I think that
> starts by agreeing on who the intended audience is and what level of
> forward-and-backward compatibility we are going to commit to [*],
> documenting that agreement, and then come up with a plan to deliver
> that during the L cycle. I'd like to start the discussion now, so I
> have put it on the agenda for Monday, but I also expect it will be a
> topic at the Vancouver summit.
>
> -Devananda
>
>
> [*] full disclosure
>
> I believe we have to commit to building a client that works well with
> every release since Icehouse, and the changes we've introduced in the
> client in this cycle do not.
>
> __________________________________________________________________________
> 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

Reply via email to