[jira] [Updated] (CASSANDRASC-23) Set up structure for handling multiple Cassandra versions

["Jon Haddad (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRASC-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jon Haddad updated CASSANDRASC-23:
----------------------------------
                        Authors: Jon Haddad
    Test and Documentation Plan: 
[CircleCI|https://app.circleci.com/pipelines/github/rustyrazorblade/cassandra-sidecar?branch=jon%2F23%2Fmultiple-cassandra-versions]


                         Status: Patch Available  (was: Open)

This patch adds support for multiple Cassandra versions by decoupling the Cassandra logic from the VertX server.  

*The Highlights*:

* The project is now broken into a few logical submodules.  A common one sits at the base, providing driver wrapper and the framework for wrapping the driver
* A Cassandra Interface, {{ICassandraAdapter}}, will provide the abstraction by which we interact with Cassandra going forward.  I've only added a simple call - {{getStatus()}}, which serves only as a placeholder to establish working tests.
* A wrapper for the ICassandra adapter, {{CassandraAdapterDelegate}}, which also implements the ICassandraAdapter interface, handles picking the right Adapter for a given connection.  The rest services only need to be given an instance of the delegate, it will automatically pick the right Cassandra version and delegate all calls to the underlying version.  If Cassandra is restarted (or upgraded), it will swap out the underlying implementation based on the version it detects when the session is available agin.  This is completely hidden from the REST services.
* A Test Template Framework, {{CassandraTestTemplate}} supported by docker via TestContainers, is provided for integration testing.  It can be used by annotating a test with {{@CassandraIntegrationTest}}.  One instance of the test will be created for each version of Cassandra we want to test against.  
* A bare bones 4.0 implementation is provided.  Other implementations can be plugged in by overriding the Guice injector, so if a team is running a fork with custom functionality, it can be used.
* Driver was upgraded to 3.9 for JDK 11 compatibility.  Otherwise exceptions are thrown due to reflection usage in Netty.
* The docs build was failing because it was running in a Docker container.  I've updated the circle ci config to only generate docs in the docs build, otherwise it fails.
* The REST service can (and does) mock the results of the Cassandra Delegate.  This allows us to test every result coming back from Cassandra.

*Note*: I still need to update the developer documentation, it's a bit lacking in details.

*Follow up work*:

* The test template references the 4.0 implementation directly.  I'd like to set up a bit of service discovery or allow the configuration to be specified via a system property, I lean toward the latter (less magic), but I don't hold that view very strongly at all.
* The circle ci configuration should be updated to cache the tarballs between runs so they don't need to be re-downloaded every time.  I've added a {{sidecar.tarballs}} property that controls where the tarballs are cached, we just need to set this and cache the location.
* We need to determine the structure for {{ICassandraAdapter}}.  I lean towards composing together small interfaces (ICompaction, IRepair, etc) so we can keep it from becoming a giant megaclass.  I believe that's best done outside this ticket.


> Set up structure for handling multiple Cassandra versions
> ---------------------------------------------------------
>
>                 Key: CASSANDRASC-23
>                 URL: https://issues.apache.org/jira/browse/CASSANDRASC-23
>             Project: Sidecar for Apache Cassandra
>          Issue Type: Improvement
>          Components: Configuration
>            Reporter: Jon Haddad
>            Assignee: Jon Haddad
>            Priority: Normal
>
> The first sidecar release will be for Cassandra 4.0, but one of the project goals is to be able to handle multiple versions.  This will be especially important in mixed version clusters, or even mixed version 1:N sidecar to C* nodes (see CASSANDRASC-17).
> This JIRA is to lay the foundational work for supporting multiple Cassandra versions. 
> Each Cassandra version (for example \{{cassandra40}}, \{{cassandra50}}, will be in a separate Gradle subproject, implementing a common interface defined in a \{{common}} subproject.  A common cassandra integration testing framework will be able to test every version to ensure each version adheres to the expected interface.
> Each module will define the minimum compatibility it supports, so if someone (for example) wants to implement a Cassandra30 module for their own cluster, they will have the ability to do so.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org