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 <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
