On Fri, Jun 26, 2015 at 7:39 AM, Dmitry Tantsur <dtant...@redhat.com> wrote:
> On 06/26/2015 04:08 PM, Sean Dague wrote: > >> On 06/26/2015 07:43 AM, Dmitry Tantsur wrote: >> >>> On 06/26/2015 01:14 PM, Sean Dague wrote: >>> >>>> On 06/16/2015 09:51 AM, Dmitry Tantsur wrote: >>>> >>>>> On 06/16/2015 08:56 AM, Dmitry Tantsur wrote: >>>>> >>>>>> To sum this long post up, I'm seeing that hiding new features based on >>>>>> microversions brings much more problems, than it solves (I'm not aware >>>>>> of the latter at all). I'm very opposed to continuing doing it in >>>>>> Ironic, and I'm going to propose patch stopping gating Kilo changes >>>>>> (non-breaking obviously). >>>>>> >>>>> >>>>> I'm talking about this patch: https://review.openstack.org/#/c/192196/ >>>>> We have to do it right now, as otherwise we can't test inspection in >>>>> tempest (it does not seem to be microversion-aware). >>>>> >>>> >>>> Dmitry, >>>> >>>> How do you solve for the following situation? >>>> >>>> 2 Clouds (A and B), both being Continuously Deployed. >>>> >>>> Assume both clouds start at same revision of code. At point in time T a >>>> new "compatable change" is added to the API. For instance, another field >>>> returned by some resource. >>>> >>>> Cloud B upgrades to that change. >>>> >>>> Brand new developer shows up. Starts writing application against Cloud >>>> B. Sees that change is available at version 1.4. Hard codes her >>>> application to use this parameter. >>>> >>>> Then she points her application at Cloud A. And it explodes. >>>> >>> >>> I clearly agree that my solutions do not solve this situation. Neither >>> does yours. Now let us see: >>> >>> A compatible change is getting added and is guarded behind version 1.5. >>> A new developer starts requiring this new version, because she needs >>> this new feature (that's your assumption). >>> >>> Then she points her application at cloud A. And it explodes. But with >>> different error message and probably a bit earlier. But explodes. >>> >>> Which, by the way, means we still must know precisely which API version >>> is served by all clouds we might apply our utility to. >>> >> >> But it fails with "Your application is attempting to use API 1.5 which >> is not supported in this cloud". Because if you don't specify a version, >> you get the base 1.0, and never had new features. >> >> That's an error which is extremely clear to understand what went wrong. >> Has docs to figure out if the application could work at an earlier >> release version, and provides the ability for the client to do some >> selection logic based on supported versions. >> > > I agree that error is clear. I'm not sure it's worth doing despite all the > problems that I mentioned in the beginning of this thread. In particular, > situation around official CLI and testing. > > E.g. do you agree with Jim that we should make API version a required > argument for both CLI and Python library? > > > >> -Sean >> >> >>> So I agree, hitting API version error could make a person realize that a >>> change to the utility is no longer compatible with the current version >>> of API. So if this change wasn't intended - fine. If it was (which is >>> the most likely situation), it won't help you. >>> >>> By the way, I've heard some people wanting to deprecate API version with >>> time. If we do so, it will open some new horizons for breakages. >>> If we don't, we'll soon end put with dozens of version to support and >>> test. How to solve it? (in Ironic IIRC we just only gate test one >>> version, namely Kilo aka 1.6, which is very, very bad IMO). >>> >>> >>>> >>>> I feel like in your concerns there has been an assumption that the >>>> operation across all clouds effectively always goes forwards. But >>>> because we're trying to encourage and create a multicloud ecosystem a >>>> user application might experience the world the following way. >>>> >>>> Cloud A -> Cloud A' -> Cloud A'' -> Cloud D -> Cloud B' -> Cloud C -> >>>> Cloud C'. >>>> >>> >>> I think that versioning actually encourages this (wrong) assumption. >>> Because versions grow with time naturally, and we, the developers, like >>> new and shiny stuff so much :) see below for my alternative idea. >>> >>> >>>> While no individual cloud is likely to downgrade code (though we can't >>>> fully rule that out), the fact that we'd like applications to work >>>> against a wide range of deployments means effectively applications are >>>> going to experience the world as if the code bases both upgrade and >>>> downgrade over time. >>>> >>>> Which means that a change is only "compatable" if the inverse of the >>>> change is also "compatable". So a field add is only compatable if the >>>> field delete is also considered compatible, because people are going to >>>> experience that when they hop to another cloud. >>>> >>>> Which is also why feature hiding is a thing. Because we don't control >>>> when every cloud is going to upgrade, and what they'll upgrade to. So >>>> the best idea so far about getting this right is that API 1.4 is >>>> *exactly* a specific surface. Features added in 1.5 are not visibile if >>>> you ask for 1.4. Because if they were, and you now wrote applications >>>> that used that bleed through, when you jump to a cloud without 1.5 yet >>>> deployed, all your application code breaks. >>>> >>> >>> Note that if you rely on version 1.4 with feature hiding, your >>> application will also break. I.e. I agree it's a valid situation to fix, >>> I just don't see feature hiding fixing *all* cases of this problem. >>> While an API exposing feature explicitly might be more handy, imagine >>> e.g. >>> >>> $ curl http://ironic.host/v1/features >>> ['inspection', 'raid', ...] >>> >>> Exposing interface like that would encourage people to think about their >>> application in terms of mandatory and optional features, not some >>> numbers. >>> >> >> Yes, version number is being used as a proxy for a feature description. >> Which is what version numbers are used for in software. It's a way to >> let people think about bundles of things, instead of having to mentally >> map out every single feature in their head. >> > > Why do you think it's good? People are using features, not numbers. They > don't need to map out features - on the contrary they do need to map > versions to features. We've reached 1.8 with Ironic - and I (the core) > don't remember what were these version about, except for 1.6. Does Ironic have a document explaining each API version? I quick search in the source tree didn't turn anything up. Being able to easily figure out what each API version do is important for end users. As a user, when I see the cloud I use now supports nova API 2.26 I want an easy way of figuring out what that actually means. To address this, nova has the following document: http://docs.openstack.org/developer/nova/api_microversion_history.html > > > >> Maybe we can some day to a place where we can have an API that's fully >> feature describing, and doesn't need numbers. But after 2.5 years of >> trying to do a major rewrite of the Nova API, it was pretty clear that >> APIs of any reasonable size just can't do that. And can't rely on >> software to keep up with your changes. This provides a mechanism for >> evolution with a stability contract that API 1.4 is going to keep >> looking exactly the same over time. So you can upgrade client code on >> your schedule, not on the schedule of the server upgrades. >> > > I don't see any problem with creating an API serving list of strings, and > then making contributors update this list every time they change API. It's > the same as making contributors bump version number. > Nova has already been down that path, our microversion spec discusses a few of the issues we found (It doesn't go into a lot of detail though): http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html#problem-description Additionally the extensions model doesn't support backwards incompatible changes. > >> -Sean >> >> > > __________________________________________________________________________ > 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
