I agree, we need a discussion asap. I think below things can mitigate the unexpected behavior of python client and this is borrow from object model. 1. Python client should have its own version and attributes like supported api version. 2. It should be able to recognize the server's version and show corresponding fields instead of all.
B.R Tan -----Original Message----- From: Devananda van der Veen [mailto:devananda....@gmail.com] Sent: Sunday, March 8, 2015 8:12 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Ironic] Thinking about our python client UX 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
