Negotiation is useful for handling functional changes that are not expressible in IDL.
On Thu, Mar 5, 2015 at 5:01 PM, lars hofhansl <[email protected]> wrote: > > We want a 3.0 client able to talk to a 2.0 cluster? > Not necessarily. But a 2.0 client to talk to a 3.0? You bet :)If pb is > good enough to have us never break the protocol between an old client and > new server even across major version, I (with my work hat on) am happy. > -- Lars > > From: Stack <[email protected]> > To: HBase Dev List <[email protected]>; lars hofhansl < > [email protected]> > Cc: Nick Dimiduk <[email protected]> > Sent: Thursday, March 5, 2015 4:51 PM > Subject: Re: Client-Server wire compatibility? > > On Thu, Mar 5, 2015 at 4:23 PM, lars hofhansl <[email protected]> wrote: > > > Thanks Nick, yep, that's exactly how we should phrase it (IMHO, anyway). > > Does this need clarification in the book? > > > > So... Should we think about client-server protocol version negotiation, > > maybe in 2.0? We'd need the negotiation itself, as well as some > refactoring > > to pass that version information down to where it matters (i.e. all > actions > > that might be executed on behalf of an RPC). > > > > We had 'negotiation' in the rpc at one time but it was stripped out because > it was just broke; it had never been exercised. > > What we want to negotiate? > > pb gives us a bit of wiggle room to add/ignore params. We need more? > > We want a 3.0 client able to talk to a 2.0 cluster? > > St.Ack > > > > > > > > > > > > > I'm not too worried about one-way compatibility (old client, new server), > > but more about what we'd do when we actually want to break the protocol > in > > a major release.Some groups (like where I work) run clients in the long > > running app server hosting a lot of other code and services, and we > cannot > > upgrade client and server in lockstep without down time. Thrift/etc are > not > > an option for us for performance reasons.We'll likely resort to classload > > isolation (OSGi, and friends) to let us load multiple versions of the > > client into the same JVM and pick the right one during time where two > > versions of HBase are out there... But we'd rather not do that :) > > > > -- Lars > > From: Nick Dimiduk <[email protected]> > > To: hbase-dev <[email protected]> > > Cc: lars hofhansl <[email protected]> > > Sent: Thursday, March 5, 2015 3:22 PM > > Subject: Re: Client-Server wire compatibility? > > > > Then to answer Matteo's original question, I guess the answer is "it > > depends". If the client embedded in servers is never used to call your > > modified RPC, we're fine with new clients not working with old servers. > > However, if it's a server that's using the modified RPC (new RS using new > > client to scan META on old RS, for instance), the implementation must be > > done in a mutually compatible way. > > > > > > On Thu, Mar 5, 2015 at 1:33 PM, Andrew Purtell <[email protected]> > > wrote: > > > > +1 client-server negotation > > > > I filed several JIRAs regarding connection setup negotiation around the > > 0.98.0 timeframe. I wanted to negotiate what cell codecs should be used > on > > the connection, somehow compatible with 0.96. Unfortunately this didn't > > bear fruit. We should definitely have client-server protocol negotiation > so > > we can gracefully handle the type of situation under discussion here. > We'd > > have fallback compensation on both the client and server sides for > talking > > with an older version. We should decide under what circumstances > fallbacks > > can be removed. (Perhaps, after one major version increment.) > > > > > > On Thu, Mar 5, 2015 at 1:15 PM, lars hofhansl <[email protected]> wrote: > > > > > To take a step... The discussion was around whether we can generally > > break > > > a new client talking an old cluster.From a client-server perspective > that > > > should be OK (IMHO), and that is how we stated it in the compatibility > > doc. > > > If the client-server protocol is broken in such a way that (f.e.) an > new > > > HMaster can no longer access META on an old RegionServer we have broken > > > server-server compatibility, which we said we wouldn't in order to > > support > > > rolling upgrades. > > > Re: negotiationg... > > > I have been saying the in first meeting we had about protobufs that we > > > should build a client-server negotiation phase where client and server > > > agree on which version of the protocol they'll use to communicate > > (provide > > > the intersection between the sets of the supported version is not > > > empty).Back than I was the only one arguing in that direction. Stating > > that > > > we'll only guarantee an old client with a new server seemed to be the > > next > > > best thing to be reasonably flexible in how we evolve things and > allowing > > > users a no-downtime upgrade path. > > > > > > An example is: We add a new RPC to HBase.When the new client is used > > > against an old cluster, it would need to be able to fail gracefully > when > > > that new RPC is used.If we only support the old client against a new > > > cluster we won't have that problem (and we'd be free to add new stuff > as > > we > > > see fit, as long as we do break old RPCs) > > > As long as the servers do not use that RPC amongst each other, we have > > not > > > broken server-server compatibility, and hence we are able to make > change > > > like in a minor version. > > > > > > Does this make sense? Is that what you guys had in mind? Or do think we > > > need to be stricter? > > > > > > -- Lars > > > > > > From: Nick Dimiduk <[email protected]> > > > To: hbase-dev <[email protected]> > > > Cc: lars hofhansl <[email protected]> > > > Sent: Thursday, March 5, 2015 12:37 PM > > > Subject: Re: Client-Server wire compatibility? > > > > > > On Thu, Mar 5, 2015 at 12:24 PM, Stack <[email protected]> wrote: > > > > > > On Thu, Mar 5, 2015 at 12:18 PM, lars hofhansl <[email protected]> > wrote: > > > > > > > Then we have broken server-server compatibility, which the doc state > we > > > > won't break for patch and minor versions. > > > > > > What is broke? A 1.1 client can't scan a 1.0 meta? > > > > > > > > > My thinking is that the fall-back approach would enable the new client > > > code to communicate with either server version. Kind of a poor-man's > > > feature negotiation protocol. > > > Can you elaborate Lars? > > > > > > > > > > > > > -- Lars > > > > From: Andrey Stepachev <[email protected]> > > > > To: [email protected] > > > > Sent: Thursday, March 5, 2015 9:48 AM > > > > Subject: Re: Client-Server wire compatibility? > > > > > > > > Hi Nick, > > > > > > > > > I suppose it's possible the client in the master is never used > > outside > > > of > > > > localhost, I haven't checked that bit. > > > > > > > > Client is definitely used to access meta, which can be hosted > anywhere, > > > > so basically we can face with situation when master is upgraded and > > > > hits old region server. > > > > > > > > > > > > > > > > On Thu, Mar 5, 2015 at 5:21 AM, Nick Dimiduk <[email protected]> > > wrote: > > > > > > > > > My point was that we cannot make this guarantee as there's a client > > > > > embedded in the master (and perhaps other places). We can't enforce > > the > > > > > order in which components are upgraded, which makes it possible for > > the > > > > new > > > > > client in the new master to reach out to an old RS during the > rolling > > > > > upgrade. > > > > > > > > > > I suppose it's possible the client in the master is never used > > outside > > > of > > > > > localhost, I haven't checked that bit. > > > > > > > > > > On Wednesday, March 4, 2015, lars hofhansl <[email protected]> > wrote: > > > > > > > > > > > The idea actually was that a new client can never be 100% > > supported, > > > > > since > > > > > > a user could use it accessing new features that the server does > not > > > > > > understand.The reverse is always possible, since the old client > can > > > > > expose > > > > > > anything new unduly we can always upgrade the server as old as it > > > > doesn't > > > > > > break the old client. > > > > > > Supporting both ways is too limiting I think, at least for minor > > > > version. > > > > > > For example we might want to add a *new* RPC.As long as we only > > > support > > > > > old > > > > > > client with new servers we can do that. In any other combination > > that > > > > > would > > > > > > not (as easily) possible. > > > > > > That's why I phrased it only that way in my version proposal. > > > > > > > > > > > > For patch releases it's reasonable to support it both ways.The > book > > > is > > > > > > currently unavailable from the HBase site, so I can't check the > > exact > > > > > > wording we ended up with. > > > > > > > > > > > > -- Lars > > > > > > From: Nick Dimiduk <[email protected] <javascript:;>> > > > > > > To: hbase-dev <[email protected] <javascript:;>> > > > > > > Sent: Wednesday, March 4, 2015 4:49 PM > > > > > > Subject: Re: Client-Server wire compatibility? > > > > > > > > > > > > I believe your posted example is intended to be supported. > There's > > no > > > > > > enforcement, for instance, that the master is upgraded before all > > > RS's. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 4, 2015 at 4:06 PM, Matteo Bertozzi < > > > > [email protected] > > > > > > <javascript:;>> > > > > > > wrote: > > > > > > > > > > > > > the book (http://hbase.apache.org/book.html#hbase.versioning) > > > > > > > talks about "only allow upgrading the server first" to use new > > > APIs. > > > > > > > > > > > > > > what about a new client talking to an old server for "old" > > > > operations? > > > > > > > For example: If I have a 1.1 client, can I ask a 1.0 server to > > > > create a > > > > > > > table? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Andrey. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > > > > > > > > > > > > > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
