[
https://issues.apache.org/jira/browse/CASSANDRASC-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106449#comment-17106449
]
Jon Haddad edited comment on CASSANDRASC-23 at 5/13/20, 4:38 PM:
-----------------------------------------------------------------
PR: https://github.com/apache/cassandra-sidecar/pull/14
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.
was (Author: rustyrazorblade):
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: [email protected]
For additional commands, e-mail: [email protected]
