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