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).
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 <ndimi...@gmail.com>
To: hbase-dev <dev@hbase.apache.org>
Cc: lars hofhansl <la...@apache.org>
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 <apurt...@apache.org> 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 <la...@apache.org> 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 <ndimi...@gmail.com>
> To: hbase-dev <dev@hbase.apache.org>
> Cc: lars hofhansl <la...@apache.org>
> Sent: Thursday, March 5, 2015 12:37 PM
> Subject: Re: Client-Server wire compatibility?
>
> On Thu, Mar 5, 2015 at 12:24 PM, Stack <st...@duboce.net> wrote:
>
> On Thu, Mar 5, 2015 at 12:18 PM, lars hofhansl <la...@apache.org> 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 <oct...@gmail.com>
> > To: dev@hbase.apache.org
> > 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 <ndimi...@gmail.com> 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 <la...@apache.org> 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 <ndimi...@gmail.com <javascript:;>>
> > > > To: hbase-dev <dev@hbase.apache.org <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 <
> > theo.berto...@gmail.com
> > > > <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)
