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