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. > > > > > > > > >
