26 июня 2015 г. 2:48 пользователь "GHANSHYAM MANN" <ghanshyamm...@gmail.com> написал: > > On Thu, Jun 25, 2015 at 5:18 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> wrote: > > Sorry for late response here, > > > > 2015-06-20 9:14 GMT+09:00 Devananda van der Veen < devananda....@gmail.com>: > >> > >> Long version... > >> Every HTTP response from Ironic today includes three headers: min, max, and > >> version. The service can present an older API version, as long as it is > >> greater-than-or-equal-to the minimum supported version, even if that version > >> is incompatible with the maximum supported version. It does this by > >> rewriting responses to match what was expected in the requested (older) > >> version. > >> > >> When the newer version is identical *for all interfaces present* in the > >> older version, this can be called compatible. Dmitry's point is that we > >> don't need to hide newer interfaces from users who request an older API > >> version, because the client won't know or care about things that weren't in > >> the version it requested. > >> > >> However, we *do* need to signal their presence, and we don't have a good > >> means for that right now. We also need to signal to the client that the > >> response given is "compatible with" a certain "age" of API, even if it's not > >> exactly the same. And we don't have any means for that, either. > >> > >> Time for an example.... > >> > >> Let's say that an incompatible change was made in v1.3. Let's also say that > >> a change was made in v1.5 that added a new endpoint. Today, this is what the > >> response headers would look like when calling a server running v1.5. > >> > >> a) client requests v1.2, receives headers (min: 1.1, max: 1.5, current: 1.2) > >> b) client requests v1.4, receives headers (min: 1.1, max: 1.5, current 1.4) > >> c) client requests v1.5, receives headers (min: 1.1, max: 1.5, current: 1.5) > >> > >> What we have implemented today is that in case (b), the service will *hide* > >> any changes that we introduced in v1.5. But those changes did not affect any > >> functionality of the v1.4 API, so Dmitry objects to this. So do I. > >> > >> The issue at hand is the response in case (b) ... though after spending the > >> last several months working on api versioning, I actually think all of those > >> are poor responses. > >> > >> What I believe we should have: > >> a) client requests v1.2, receives headers (min: 1.1, max: 1.5, > >> compatible-with: 1.1) > >> b) client requests v1.4, receives headers (min: 1.1, max: 1.5, > >> compatible-with: 1.3) > >> b) client requests v1.5, receives headers (min: 1.1, max: 1.5, > >> compatible-with: 1.3) > >> > >> Yes -- (b) and (c) are identical responses. > >> > >> Discuss. > > > > I think it is good that backwards compatible changes(new features) are > > available on older microversion also *only* if the clouds which are > > used by users continue upgrading. > > > > I think Sophia's role on "The Backwards Compatibility Fallacy" of > > Sean's blog[1] has answered to this question, but I'd like to try > > explaining it here for considering Ironic situation. > > As the example, there are multiple public clouds which provide > > different max microversions like: > > > > Cloud A: Max microversion: v1.5 > > Cloud B: Max microversion: v1.1 > > > > A user wrote his own application for running on cloud A and specifying > > v1.1 on the first application implementation. > > The first application used small number of APIs, and he wanted to > > extend the application. > > If all backwards compatible changes(v1.2 - v1.5) appear on lower > > microversion(in this case v1.1), he can use all new features even if > > specifying v1.1. > > That seemed really great for users at this time, and he extended the > > application for using all features as possible. > > but the specified microversion still is v1.1 because his application > > worked fine even if using newer features. > > > > After that, he needed to switch to the other cloud because of cost > > merit or something. > > The specified microversion was v1.1, so he did think his application > > can work fine on cloud B also because of cloud B's max microversion. > > But yes, his application could not work because his application had > > already used newer features which are implemented on v1.2+. > > In the real world, there are a lot of clouds and it is easy to imagine > > this situation.
By the way, feature hiding did not change the situation: the application using new features won't work on older cloud, period. > > > > This is really nice point. We should give power to users to decide whether they > need/want to use/get the new features introduced in new microversion > irrespective > of it is backward compatible or not. I'm already tried of asking why, but I'll try again: why? Did you even read this thread? It's not power, it's limitation, and a pretty nasty one. > > > > Current microversion implementation of Nova is blocking this situation > > by making backwards every compatible change appear on each > > microversion. > > Nova team needs to consider interoperability between clouds so well > > because Nova API is one of general external interfaces for end users. > > > > On the other hand, Ironic API is for administrators, not for end users. > > I am imaging that: > > * Some administrator wrote his application for using Ironic API. > > * From the viewpoint of administrator, the switching destination cloud > > in newer in most cases. > > * The application can continue working on newer clouds even after > > switching many times. > > > > So I feel the above interoperable issue example would not happen on > > Ironic in most cases unless hiding backwards compatible changes on > > lower microversion. > > I guess this is the difference between Nova and Ironic on > > interoperability discussion. > > > > I cannot/don't want to enforce Ironic way at all, and it's fine to > > find the best way on each project as OSS projects. > > But only my concern here is that we cannot use "Microversions" as a > > perfect keyword for OpenStack interoperability on whole OpenStack > > projects if Ironic goes to the other way. > > > > Thanks > > Ken Ohmichi > > > > --- > > [1]: https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/ > > > > __________________________________________________________________________ > > 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 > > > > -- > Thanks & Regards > Ghanshyam Mann > > __________________________________________________________________________ > 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