On Thu, 2 Feb 2017, Ken'ichi Ohmichi wrote:
2017-02-02 9:38 GMT-08:00 Chris Dent <cdent...@anticdent.org>:
Greetings OpenStack community,
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.
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?
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
