Open Stack

26 июня 2015 г. 2:48 пользователь "GHANSHYAM MANN" <ghanshyammann at gmail.com>
написал:
>
> On Thu, Jun 25, 2015 at 5:18 PM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
wrote:
> > Sorry for late response here,
> >
> > 2015-06-20 9:14 GMT+09:00 Devananda van der Veen <
devananda.vdv at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150626/d5f45788/attachment.html>