Jacob Isaac created PHOENIX-7210:
------------------------------------

             Summary: Ensure Phoenix IT tests can be run against a real 
distributed cluster
                 Key: PHOENIX-7210
                 URL: https://issues.apache.org/jira/browse/PHOENIX-7210
             Project: Phoenix
          Issue Type: Improvement
            Reporter: Jacob Isaac


When planning a new Phoenix Release in OSS  and subsequent upgrades in 
production, we must ensure that our release build is well tested. Currently 
running the IT test suite ensures that a version (build version) of client and 
server are working as desired. A few backward compatibility tests are also run 
as part of the IT test suite but they are very minimal in coverage. The purpose 
of this JIRA is to explore how we can enhance our IT test framework to provide 
test coverage and backward compatibility for various combinations of 
client-server versions.

Our current OSS release sign-off process is as described 
[here|https://phoenix.apache.org/release.html]


Apache Phoenix follows semantic versioning i.e. for a given version x.y.z, we 
have:

* Major version:
    * x is the major version.
    * A major upgrade needs to be done when you make incompatible API changes. 
There will generally be public-facing APIs that have changed, metadata changes 
and/or changes that affect existing end-user behavior.
* Minor version:
    * y is the minor version.
    * A minor upgrade needs to be done when you add functionality in a 
backwards compatible manner. Any changes to system table schema (for ex: 
SYSTEM.CATALOG) such as addition of columns, must be done in either a minor or 
major version upgrade.
* Patch version:
    * z is the patch version.
    * A patch upgrade can be done when you make backwards compatible bug fixes. 
This is particularly useful in providing a quick minimal change release on top 
of a pre-existing minor/major version release which fixes bugs.


When upgrading the Major/Minor version we typically run tests other than the IT 
tests to cover various client/server combinations that can manifest during an 
upgrade.

1. Client with old Phoenix jar + Servers with mixed Phoenix jars + old metadata 
(few servers have been upgraded)
2. Client with old Phoenix jar + Server with new Phoenix jar + old metadata 
(bits upgraded)
3. Client with old Phoenix jar + Server with new Phoenix jar + new metadata 
(metadata upgraded)
4. Client with new Phoenix jar + Server with new Phoenix jar + new metadata 
(clients upgraded)


It would be a more exhaustive set of tests if we could run the Phoenix IT test 
suites against a distributed cluster with above combinations.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to