Client-Server wire compatibility?

[Matteo Bertozzi <th...@gmail.com>]

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?

Re: Client-Server wire compatibility?

[Andrew Purtell <ap...@apache.org>]

On Thu, Mar 5, 2015 at 12:10 AM, Matteo Bertozzi <th...@gmail.com>
wrote:

> On Thu, Mar 5, 2015 at 4:20 AM, 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.
>
>
> I think that it is fine if we have exceptions not handled when a client
> tries to ask a new features on an old server.
> but my question was about old operations. e.g. Assuming that you do a
> create table with all the arguments/configuration that the old server was
> able to understand, is it fair to have a 1.1 client that throws an
> exception against a 1.0 server because in the new 1.1 the create logic is
> not compatible?
>

​​That question hinges on why the create logic is not compatible. ​We have
guidelines that allow us flexibility to break things at clearly defined
points, but that doesn't mean we shouldn't avoid doing so wherever
possible. Why can't create remain wire compatible in this case? Is there a
JIRA?

Re: Client-Server wire compatibility?

[Matteo Bertozzi <th...@gmail.com>]

On Thu, Mar 5, 2015 at 4:20 AM, 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.


I think that it is fine if we have exceptions not handled when a client
tries to ask a new features on an old server.
but my question was about old operations. e.g. Assuming that you do a
create table with all the arguments/configuration that the old server was
able to understand, is it fair to have a 1.1 client that throws an
exception against a 1.0 server because in the new 1.1 the create logic is
not compatible?

Re: Client-Server wire compatibility?

[Stack <st...@duboce.net>]

On Thu, Mar 5, 2015 at 5:19 PM, Enis Söztutar <en...@apache.org> wrote:

> The way some of the RPC's are done today is kind of negotiation
> after-the-fact. So the client does an RPC, it can fail with
> NoSuchMethodException, in which case the client should fallback if the
> operation is supported in the old version (like create table). In some
> cases where we add a new field in the PB for requests or responses, we
> always add it as optional, and check the existence of that field to do the
> new behavior or old behavior. In this sense, it is not negotiation per-se,
> but a feature-based graceful fallback.
>
> Coming to the specifics, I think what to do for Procv2 based DDL statements
> can be achieved using a similar strategy. For example, the create table
> request is sent, and a response returned back to the client. The create
> table request is handled after the response is returned back to the client,
> and the client just waits there for observing the "side affects" of the
> create table statement execution. If for example we do procv2 based create
> table, the create table response can optionally return the proc_id to the
> client in the same response. If it is a new client talking to the new
> server the proc_id will be there, so the client can safely call proc_v2
> related RPC endpoints. If the returned response does not contain proc_id,
> then it is an old server, so it should do what it does today. This enables
> to have a client to be BC with old masters and new masters. If the client
> is old, even if the new master returns a proc_id, the client will ignore
> it.
>

Thanks.

So we make no promises for clients being able to go back in time so fine if
the Admin function fails because old server; better if it just worked but
that is nice-to-have.

For the clients hosted in server talking to old server:

We could retrofit support for generic feature negotiation (in a BC way) and
add appropriate fallbacks if wanted facility is missing. We'd be
hand-crafting this new stuff atop the custom hadoop rpc that serves as our
current transport, and we would do the testing for this generic facility to
make sure it works for those occasions it is needed.

Or we could figure what subset of server-hosted client function needs the
treatment Enis describes above to get us back our rolling upgrade inside a
minor version as per our semvar promises. Does server-hosted client do any
Admin functions?  If not, thats a set of functions we'd NOT need to make
BC. Is all that is needed a bit of Scan, Delete and Put?  If P, D and S
will do, then we need to do the above special treatment for this subset of
calls ensuring new versions can always work with old servers always.

The latter could get unmaintainable if the surface area is broad and in
flux but mayhaps we can cut it down (I've not done the research).

St.Ack

Re: Client-Server wire compatibility?

[Enis Söztutar <en...@apache.org>]

The way some of the RPC's are done today is kind of negotiation
after-the-fact. So the client does an RPC, it can fail with
NoSuchMethodException, in which case the client should fallback if the
operation is supported in the old version (like create table). In some
cases where we add a new field in the PB for requests or responses, we
always add it as optional, and check the existence of that field to do the
new behavior or old behavior. In this sense, it is not negotiation per-se,
but a feature-based graceful fallback.

Coming to the specifics, I think what to do for Procv2 based DDL statements
can be achieved using a similar strategy. For example, the create table
request is sent, and a response returned back to the client. The create
table request is handled after the response is returned back to the client,
and the client just waits there for observing the "side affects" of the
create table statement execution. If for example we do procv2 based create
table, the create table response can optionally return the proc_id to the
client in the same response. If it is a new client talking to the new
server the proc_id will be there, so the client can safely call proc_v2
related RPC endpoints. If the returned response does not contain proc_id,
then it is an old server, so it should do what it does today. This enables
to have a client to be BC with old masters and new masters. If the client
is old, even if the new master returns a proc_id, the client will ignore
it.

Enis

On Thu, Mar 5, 2015 at 5:01 PM, lars hofhansl <la...@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 <st...@duboce.net>
>  To: HBase Dev List <de...@hbase.apache.org>; lars hofhansl <
> larsh@apache.org>
> Cc: Nick Dimiduk <nd...@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 <la...@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 <nd...@gmail.com>
> >  To: hbase-dev <de...@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 <ap...@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 <nd...@gmail.com>
> > >  To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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)
> >
> >
> >
> >
> >
> >
>
>
>
>

Re: Client-Server wire compatibility?

[Andrew Purtell <ap...@apache.org>]

Negotiation is useful for handling functional changes that are not
expressible in IDL.

On Thu, Mar 5, 2015 at 5:01 PM, lars hofhansl <la...@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 <st...@duboce.net>
>  To: HBase Dev List <de...@hbase.apache.org>; lars hofhansl <
> larsh@apache.org>
> Cc: Nick Dimiduk <nd...@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 <la...@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 <nd...@gmail.com>
> >  To: hbase-dev <de...@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 <ap...@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 <nd...@gmail.com>
> > >  To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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)

Re: Client-Server wire compatibility?

[lars hofhansl <la...@apache.org>]

> 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 <st...@duboce.net>
 To: HBase Dev List <de...@hbase.apache.org>; lars hofhansl <la...@apache.org> 
Cc: Nick Dimiduk <nd...@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 <la...@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 <nd...@gmail.com>
>  To: hbase-dev <de...@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 <ap...@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 <nd...@gmail.com>
> >  To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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)
>
>
>
>
>
>


  

Re: Client-Server wire compatibility?

[Stack <st...@duboce.net>]

On Thu, Mar 5, 2015 at 4:23 PM, lars hofhansl <la...@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 <nd...@gmail.com>
>  To: hbase-dev <de...@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 <ap...@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 <nd...@gmail.com>
> >  To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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)
>
>
>
>
>
>

Re: Client-Server wire compatibility?

[lars hofhansl <la...@apache.org>]

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 <nd...@gmail.com>
 To: hbase-dev <de...@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 <ap...@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 <nd...@gmail.com>
>  To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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)




  

Re: Client-Server wire compatibility?

[lars hofhansl <la...@apache.org>]

Yeah. Would need to define a set of features first. A version would simply stand for a distinct set of supported features... I agree that'd be less flexible.

      From: Todd Lipcon <to...@cloudera.com>
 To: dev <de...@hbase.apache.org> 
Cc: lars hofhansl <la...@apache.org> 
 Sent: Thursday, March 5, 2015 4:17 PM
 Subject: Re: Client-Server wire compatibility?
   
If you add a negotiation phase, I'd recommend doing it in terms of a
list<SupportedFeature> rather than a version number. That makes it much
easier to backport new features across branches without being forced to
backport all other features that might have been introduced between the two.

-Todd




   

Re: Client-Server wire compatibility?

[Andrew Purtell <ap...@apache.org>]

Yes,+1

On Thu, Mar 5, 2015 at 4:17 PM, Todd Lipcon <to...@cloudera.com> wrote:

> If you add a negotiation phase, I'd recommend doing it in terms of a
> list<SupportedFeature> rather than a version number. That makes it much
> easier to backport new features across branches without being forced to
> backport all other features that might have been introduced between the
> two.
>
> -Todd
>



-- 
Best regards,

   - Andy

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

Re: Client-Server wire compatibility?

[Todd Lipcon <to...@cloudera.com>]

If you add a negotiation phase, I'd recommend doing it in terms of a
list<SupportedFeature> rather than a version number. That makes it much
easier to backport new features across branches without being forced to
backport all other features that might have been introduced between the two.

-Todd

Re: Client-Server wire compatibility?

[Nick Dimiduk <nd...@gmail.com>]

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 <ap...@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 <nd...@gmail.com>
> >  To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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)
>

Re: Client-Server wire compatibility?

[Andrew Purtell <ap...@apache.org>]

+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 <nd...@gmail.com>
>  To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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)

Re: Client-Server wire compatibility?

[lars hofhansl <la...@apache.org>]

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 <nd...@gmail.com>
 To: hbase-dev <de...@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 <oc...@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 <nd...@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 <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.
>
>
>
>




  

Re: Client-Server wire compatibility?

[Nick Dimiduk <nd...@gmail.com>]

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 <oc...@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 <nd...@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 <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.
> >
> >
> >
> >
>

Re: Client-Server wire compatibility?

[Stack <st...@duboce.net>]

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?
St.Ack




> -- Lars
>       From: Andrey Stepachev <oc...@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 <nd...@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 <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.
>
>
>
>

Re: Client-Server wire compatibility?

[lars hofhansl <la...@apache.org>]

Then we have broken server-server compatibility, which the doc state we won't break for patch and minor versions.
-- Lars
      From: Andrey Stepachev <oc...@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 <nd...@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 <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.


  

Re: Client-Server wire compatibility?

[Nick Dimiduk <nd...@gmail.com>]

Thanks for confirming Andrey.

In this case, I think the appropriate approach would be for the new client
to first attempt the new RPC, look for a NoSuchMethod kind of exception,
and fall back to the old RPC. This transparent fallback would be required
as long as online compatibility is required.

-n

On Thursday, March 5, 2015, Andrey Stepachev <oc...@gmail.com> wrote:

> 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
> <javascript:;>> 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
> <javascript:;>> 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:;>
> <javascript:;>>
> > >  To: hbase-dev <dev@hbase.apache.org <javascript:;> <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:;>
> > > <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.
>

Re: Client-Server wire compatibility?

[Andrey Stepachev <oc...@gmail.com>]

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

Re: Client-Server wire compatibility?

[Nick Dimiduk <nd...@gmail.com>]

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

Re: Client-Server wire compatibility?

[lars hofhansl <la...@apache.org>]

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 <nd...@gmail.com>
 To: hbase-dev <de...@hbase.apache.org> 
 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 <th...@gmail.com>
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?
>


   

Re: Client-Server wire compatibility?

[Nick Dimiduk <nd...@gmail.com>]

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 <th...@gmail.com>
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?
>