[jira] [Commented] (PHOENIX-5607) Client-server backward compatibility tests

["Lars Hofhansl (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16990605#comment-16990605 ] 

Lars Hofhansl commented on PHOENIX-5607:
----------------------------------------

Options to implement better backward compatibility.
 * Strictly version the server side schema.
 * Abstract meta data operation into a clean API and endpoints. MetadataEndpointImpl is a start, but it is not at all complete.
 * Keep old endpoint APIs around with the *identical* behavior for old clients. (Perhaps the implementation would change in terms of a new internal schema, but the behavior has to be maintained.)
 * Keep old protobuf definitions around (or make 100% they are backward compatible.)
 * Negotiate the client and server versions for each metadata API call.
 * New behavior would always get a new API and endpoint and new (or 100% compatible) protobufs.
 * At some point we can retire the older endpoints (no longer supporting that old client).

 

Scenarios to test:
 # Start with old cluster, upgrade servers. Do not connect with a new client. Connect with old client and run various tests: create tables, indexes, views, indexes on views, add columns, drop columns, views, tables, and indexes, etc.
 # Start with old cluster, upgrade servers. Connect with new client (causing the system upgrade). Connect with old client and run various tests: create tables, indexes, views, indexes on views, add columns, drop columns, views, tables, and indexes, etc.
 # Start with old cluster. Set upgrade enabled to false. Connect with new client. Verify that EXECUTE UPGRADE works. Connect with old client and run various tests: create tables, indexes, views, indexes on views, add columns, drop columns, views, tables, and indexes, etc.
 # Start view new cluster. Connect with old client and run various tests: create tables, indexes, views, indexes on views, add columns, drop columns, views, tables, and indexes, etc.
 # (Probably some more)

Ideally we can run the entire test suite for all of these scenarios, although that would be prohibitively slow.

Implementing these types of tests is tricky. We'd have to check in an jar with the old version of the client, and use that from within the ITs.

This is bigger issue and would probably be implemented in multiple sub jiras.

 

> Client-server backward compatibility tests 
> -------------------------------------------
>
>                 Key: PHOENIX-5607
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5607
>             Project: Phoenix
>          Issue Type: Test
>    Affects Versions: 4.15.0
>            Reporter: Lars Hofhansl
>            Priority: Blocker
>             Fix For: 4.16.0
>
>
> Filing this as a blocker for 4.16.0.
> As we've seen with the various failed attempts to release 4.15.0 Phoenix' backwards compatibility story is weak, and lacks tests - in fact there're no tests.
> We should not allow to ship 4.16.0 without improving that and without tests.
> [~ChinmayKulkarni], [~gjacoby] , FYI, what we discussed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)