Re: [openstack-dev] [Ironic] Thinking about our python client UX
On 11 March 2015 at 18:21, Robert Collins robe...@robertcollins.net wrote: ... Since there was no debate on the compat thing, I've thrown up an etherpad to start the discussion. https://etherpad.openstack.org/p/ironic-client-ux Thanks Rob. Michael Davies has a spec [1] that discusses how a client interacts with Ironic (pre-microversion and post-microversion). Maybe we can move our discussion to that spec? I was hoping we'd be able to decide and implement *something* for the kilo release, but maybe I am being overly optimistic. --ruby [1] https://review.openstack.org/#/c/161110/ __ 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
Re: [openstack-dev] [Ironic] Thinking about our python client UX
On 8 March 2015 at 13: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. Since there was no debate on the compat thing, I've thrown up an etherpad to start the discussion. https://etherpad.openstack.org/p/ironic-client-ux -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
Re: [openstack-dev] [Ironic] Thinking about our python client UX
Oh, sure - switching to the spec is fine, I didn't realise there was one, given the list thread had gone quiet :) -Rob On 12 March 2015 at 12:24, Ruby Loo rlooya...@gmail.com wrote: On 11 March 2015 at 18:21, Robert Collins robe...@robertcollins.net wrote: ... Since there was no debate on the compat thing, I've thrown up an etherpad to start the discussion. https://etherpad.openstack.org/p/ironic-client-ux Thanks Rob. Michael Davies has a spec [1] that discusses how a client interacts with Ironic (pre-microversion and post-microversion). Maybe we can move our discussion to that spec? I was hoping we'd be able to decide and implement *something* for the kilo release, but maybe I am being overly optimistic. --ruby [1] https://review.openstack.org/#/c/161110/ __ 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 -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
Re: [openstack-dev] [Ironic] Thinking about our python client UX
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
Re: [openstack-dev] [Ironic] Thinking about our python client UX
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
