2017-02-03 9:56 GMT-08:00 Chris Dent <cdent...@anticdent.org>: > On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote: >>> >>> In today's meeting [0] after briefly covering old business we spent >>> nearly >>> 50 minutes going round in circles discussing the complex interactions of >>> expectations of API stability, the need to fix bugs and the costs and >>> benefits of microversions. We didn't make a lot of progress on the >>> general >>> issues, but we did #agree that a glance issue [4] should be treated as a >>> code bug (not a documentation bug) that should be fixed. In some ways >>> this >>> position is not aligned with the ideal presented by stability guidelines >>> but >>> it is aligned with an original goal of the API-WG: consistency. It's >>> unclear >>> how to resolve this conflict, either in this specific instance or in the >>> guidelines that the API-WG creates. As stated in response to one of the >>> related reviews [5]: "If bugs like this don't get fixed properly in the >>> code, OpenStack risks going down the path of Internet Explorer and people >>> wind up writing client code to the bugs and that way lies madness." >> >> >> I am not sure the code change can avoid the madness. > > > Just for the record, I'm not the speaker of that quote. I included > it because I think it does a good job of representing the complexity > and confusion that we have going on or at least in inspiring > responses that help to do so. > > Which is a round about way of saying: Thank you very much for > responding.
Haha, I see. >> If we change the success status code (200 ->204) without any version >> bumps, OpenStack clouds return different status codes on the same API >> operations. >> That will break OpenStack interoperability and clients' APPs need to >> be changed for accepting 204 also as success operation. >> That could make APPs code mudness. >> I also think this is basically code bug, but this is hard to fix >> because of big impact against the existing users. > > > There have been lots of different opinions and perspective on this > (in the reviews and elsewhere), all of which are pretty sensible but > as a mass are hard to reconcile. The below is reporting evidence, not > supporting a plan: > > The API-WG is striving for OpenStack APIs to be consistent within > themselves, with each other and with the HTTP RFCs. This particular > issue is an example where none of those are satisfied. > > Yet it is true that if client code is specifically looking for a > 200 response this change, without a version signal, will break > that code. > > But glance isn't set up with microversions or something like. > > But isn't checking specifically for 200 as "success" unusual so > this is unlikely to be as bad as changing a 4xx to some other > 4xx. > > But correcting the docs so they indicate this one request out of > several in a group breaks the 204 pattern set by the rest of > the group and could easily be perceived as a typo and thus need > to be annotated as "special". > > How do we reconcile that? This API has been implemented since 2 years ago, and it is easy to imagine many users are using the API. If changing success status code like this, we send a message "status code could be changed anytime" to users and users would recognize "the success status code is unstable and it is better to check status code range(20X) instead of a certain code(200, 201, etc) for long-term maintenance". If the above is we expect/hope, why should we fix/change success code to ideal one? On the above scenario, we are expecting users should not check a certain code. So even if changing status code, users would not be affected by the change. Whom we are changing the status code for? That seems a dilemma. Thanks Ken Ohmichi --- > Some opinions of my own: > > I worry that we're making it ever harder to fix bugs and technical > debt in many areas of OpenStack. Sure, there are very good reasons > for the constraints we build in, but how much tech debt are we > making ourselves carry? We have the versioning concepts to help (for > those projects that use them) but we haven't yet agreed how to > cleanly deprecate past stuff or even if we can or should. > > I don't feel too bad about that worry, because I know there are > plenty of people who worry about other things that balance it out > for a reasonable compromise. > > > -- > Chris Dent ¯\_(ツ)_/¯ https://anticdent.org/ > freenode: cdent tw: @anticdent > > __________________________________________________________________________ > 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
