Yes, you have identified the issues I perceive. A proxy is one acceptable solution, yes. But given the statements people have made about wanting to keep things around like the 1.x batchwriter API, I question how acceptable running proxies will be / the cost of implementing and maintaining a full proxy for a subset of features we require for compatibility.
I wish I had a better solution to punting until we have 2.0's client API finalized, but I see little recourse for any API guarantees we make for 2.0.0 until we have that API in hand. On Thu, Dec 4, 2014 at 12:29 PM, Sean Busbey <[email protected]> wrote: > On Thu, Dec 4, 2014 at 11:11 AM, Josh Elser <[email protected]> wrote: > > > John Vines wrote: > > > >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner<[email protected]> wrote: > >> > >> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser<[email protected]> > >>> wrote: > >>> > >>> John Vines wrote: > >>>> > >>>> Though I feel the biggest reasoning is our switch to semantic > >>>>> > >>>>>> versioning. And from semver.org, > >>>>>> > >>>>>>> > > >>>>>>> > >>>>>>>> > > >>>>>>>> > 1. MAJOR version when you make incompatible API changes > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > >>>>>>> Right and dropping deprecated APIs is an incompatible change. Do > >>>>>>> you > >>>>>>> > >>>>>> think > >>>>>> > >>>>>>> the following two rules are reasonable? > >>>>>>> > >>>>>>> * When API is deprecated, must offer replacement if feasible. > >>>>>>> * Can only drop deprecated method when MAJOR version is > >>>>>>> > >>>>>> incremented > >>> > >>>> (there > >>>>> > >>>>> are other proposed constraints on dropping deprecated methods) > >>>>>>> > >>>>>>> If we follow the above, then we can not deprecate current API > >>>>>>> before > >>>>>>> introducing new API (because the replacement would not exist > >>>>>>> concurrently). Also we can not drop the current API in 2.0.0 if > >>>>>>> its > >>>>>>> > >>>>>> not > >>>>>> > >>>>>>> deprecated. > >>>>>>> > >>>>>> It is totally a reasonable statement for after 2.0.0. But for 2.0.0 > I > >>>>> am > >>>>> not okay making this guarantee because I would rather sacrifice > >>>>> backward > >>>>> compatibility for an API that isn't plagued by shortcomings of the > old > >>>>> > >>>> API > >>> > >>>> Again, this is the fear/concern of impacting the new API due to > >>>> > >>> supporting > >>> > >>>> of the old which *may or may not even happen*. > >>>> > >>>> Good point, we could adopt these rules now and never create a new > >>> API. I > >>> think we would be better off adopting this now regardless of wether not > >>> we > >>> introduce a new API in the future. > >>> > >>> Also, if we do eventually create an API. How is it user unfriendly to > >>> have > >>> the old API around in deprecated form? The deprecation markings > clearly > >>> communicate that someone writing new code should not use the old API. > >>> However it still allows existing code that users invested time into > >>> writing > >>> to run w/o issue against 2.0.0. > >>> > >>> > >> I feel like I'm repeating myself. My concern is that the implementation > >> details of maintaining the 1.x API in deprecated form will have a > negative > >> impact on the 2.0 API due to implementation details. > >> > > > > Sorry, Keith, you misinterpreted what I meant -- let me try to restate. I > > am assuming that a new API will happen. > > > > What is only a possibility is that the old API implementation would > > negatively affect the new API. John's concern is a hypothetical one that > > isn't based on any *actual* implementation details. He's assuming that we > > will hit some sort of roadblock which we would be unable to resolve in a > > desirable way (a way that would not negatively impact 2.0 API). > > > > What I'm saying is that we should address those issues if and when we get > > there. When we have context to a concrete problem, we can make a decision > > there about how to proceed. Meanwhile, we act under best-intentions to > keep > > the 1.0 APIs around. > > > > Do you get what I'm suggesting, John? > > > > > I think that if we make a promise now, in this vote, that we are going to > keep (some subset of) 1.x APIs alive during the 2.x release frame, we will > be hard pressed to pass a vote to go back on that promise in 6-9 months > when the changes for 2.x get firmer. I think this is the crux of John's > opposition. > > If I understand the rest of John's concern correctly, the risk of keeping > around the old 1.x API having an impact on the form of the new 2.x API is > largely tied to involvement in the RPC layer. > > In the event that the 2.x API wants a change to the RPC that isn't > compatible with the 1.x API, one mitigation strategy (albeit extreme) is to > rely on a proxy to do the translation between old clients and a cluster > running the new services. Such a proxy may need to be non-trivial depending > on how well we're trying to support the 1.x API. For example, if we want > all of the batch writer stuff to work we may need to have a proxy service > running alongside each tserver. We could easily set acceptance criteria > for 1.x compatibility that bounds how much of e.g. a performance hit the > proxy introduces for folks upgrading from 1.x. The important bit is that > whatever form the proxy takes, it would be optional and only needed for > folks who want compatibility with the 1.x API. > > John, does it sound like I understand your concerns correctly? > > Does the above outline of a proxy based mitigation for having 1.x and 2.x > APIs coexist help at all? > > -- > Sean >
