hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Client-Server wire compatibility?
Date Fri, 06 Mar 2015 22:08:05 GMT
Negotiation is useful for handling functional changes that are not
expressible in IDL.

On Thu, Mar 5, 2015 at 5:01 PM, lars hofhansl <larsh@apache.org> 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 <stack@duboce.net>
>  To: HBase Dev List <dev@hbase.apache.org>; lars hofhansl <
> larsh@apache.org>
> Cc: Nick Dimiduk <ndimiduk@gmail.com>
>  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 <larsh@apache.org> 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 <ndimiduk@gmail.com>
> >  To: hbase-dev <dev@hbase.apache.org>
> > Cc: lars hofhansl <larsh@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 <apurtell@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 <larsh@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 <ndimiduk@gmail.com>
> > >  To: hbase-dev <dev@hbase.apache.org>
> > > Cc: lars hofhansl <larsh@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 <stack@duboce.net> wrote:
> > >
> > > On Thu, Mar 5, 2015 at 12:18 PM, lars hofhansl <larsh@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 <octo47@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 <ndimiduk@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 <larsh@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 <ndimiduk@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.bertozzi@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)
> >
> >
> >
> >
> >
> >
>
>
>
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message