<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 3, 2017 at 7:51 PM, Ken'ichi Ohmichi <span dir="ltr"><<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">2017-02-03 9:56 GMT-08:00 Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>>:<br>
> On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:<br>
>>><br>
</span><div><div class="gmail-h5">>>> In today's meeting [0] after briefly covering old business we spent<br>
>>> nearly<br>
>>> 50 minutes going round in circles discussing the complex interactions of<br>
>>> expectations of API stability, the need to fix bugs and the costs and<br>
>>> benefits of microversions. We didn't make a lot of progress on the<br>
>>> general<br>
>>> issues, but we did #agree that a glance issue [4] should be treated as a<br>
>>> code bug (not a documentation bug) that should be fixed. In some ways<br>
>>> this<br>
>>> position is not aligned with the ideal presented by stability guidelines<br>
>>> but<br>
>>> it is aligned with an original goal of the API-WG: consistency. It's<br>
>>> unclear<br>
>>> how to resolve this conflict, either in this specific instance or in the<br>
>>> guidelines that the API-WG creates. As stated in response to one of the<br>
>>> related reviews [5]: "If bugs like this don't get fixed properly in the<br>
>>> code, OpenStack risks going down the path of Internet Explorer and people<br>
>>> wind up writing client code to the bugs and that way lies madness."<br>
>><br>
>><br>
>> I am not sure the code change can avoid the madness.<br>
><br>
><br>
> Just for the record, I'm not the speaker of that quote. I included<br>
> it because I think it does a good job of representing the complexity<br>
> and confusion that we have going on or at least in inspiring<br>
> responses that help to do so.<br>
><br>
> Which is a round about way of saying: Thank you very much for<br>
> responding.<br>
<br>
</div></div>Haha, I see.<br>
<div><div class="gmail-h5"><br>
>> If we change the success status code (200 ->204) without any version<br>
>> bumps, OpenStack clouds return different status codes on the same API<br>
>> operations.<br>
>> That will break OpenStack interoperability and clients' APPs need to<br>
>> be changed for accepting 204 also as success operation.<br>
>> That could make APPs code mudness.<br>
>> I also think this is basically code bug, but this is hard to fix<br>
>> because of big impact against the existing users.<br>
><br>
><br>
> There have been lots of different opinions and perspective on this<br>
> (in the reviews and elsewhere), all of which are pretty sensible but<br>
> as a mass are hard to reconcile. The below is reporting evidence, not<br>
> supporting a plan:<br>
><br>
>   The API-WG is striving for OpenStack APIs to be consistent within<br>
>   themselves, with each other and with the HTTP RFCs. This particular<br>
>   issue is an example where none of those are satisfied.<br>
><br>
>     Yet it is true that if client code is specifically looking for a<br>
>     200 response this change, without a version signal, will break<br>
>     that code.<br>
><br>
>       But glance isn't set up with microversions or something like.<br>
><br>
>       But isn't checking specifically for 200 as "success" unusual so<br>
>       this is unlikely to be as bad as changing a 4xx to some other<br>
>       4xx.<br>
><br>
>       But correcting the docs so they indicate this one request out of<br>
>       several in a group breaks the 204 pattern set by the rest of<br>
>       the group and could easily be perceived as a typo and thus need<br>
>       to be annotated as "special".<br>
><br>
> How do we reconcile that?<br>
<br>
</div></div>This API has been implemented since 2 years ago, and it is easy to<br>
imagine many users are using the API.<br>
If changing success status code like this, we send a message "status<br>
code could be changed anytime" to users and users would recognize "the<br>
success status code is unstable and it is better to check status code<br>
range(20X) instead of a certain code(200, 201, etc) for long-term<br>
maintenance".<br></blockquote><div><br></div><div>I think we should be pragmatic. There's a a difference between changing one return code from 200->204 (still in the 2XX range), for one endpoint exceptionally and saying "we keep changing status code, OpenStack is not stable". </div><div><br></div><div>Microversions are great, but not all projects support them yet. In the mean time, if a project properly documents through a release note a minor API change (like this one), that sounds reasonable. Sure some user code will break, at upgrade, but let's be realistic here things get broken after a major upgrade of every software, that's why operators/deployers test the upgrades beforehand. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If the above is we expect/hope, why should we fix/change success code<br>
to ideal one?<br>
On the above scenario, we are expecting users should not check a certain code.<br>
So even if changing status code, users would not be affected by the change.<br>
Whom we are changing the status code for?<br></blockquote><div><br></div><div>That's a good question. In that case we should do it "for us, the developers". I prefer to work with a sane code base, sane API, small technical debt. But I also understand the users are paying us for stability. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That seems a dilemma.<br></blockquote><div><br></div><div>I would say we should make compromise, not solve dilemma. I can live in a world where we sometimes allow an API change and sometimes prevent it. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks<br>
Ken Ohmichi<br>
<br>
---<br>
<span class="gmail-im gmail-HOEnZb"><br>
> Some opinions of my own:<br>
><br>
> I worry that we're making it ever harder to fix bugs and technical<br>
> debt in many areas of OpenStack. Sure, there are very good reasons<br>
> for the constraints we build in, but how much tech debt are we<br>
> making ourselves carry? We have the versioning concepts to help (for<br>
> those projects that use them) but we haven't yet agreed how to<br>
> cleanly deprecate past stuff or even if we can or should.<br>
><br>
> I don't feel too bad about that worry, because I know there are<br>
> plenty of people who worry about other things that balance it out<br>
> for a reasonable compromise.<br>
><br>
><br>
> --<br>
> Chris Dent                 ¯\_(ツ)_/¯           <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
> freenode: cdent                                         tw: @anticdent<br>
><br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>