[
https://issues.apache.org/jira/browse/CASSANDRA-21146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069888#comment-18069888
]
Stefan Miklosovic edited comment on CASSANDRA-21146 at 3/31/26 11:21 AM:
-------------------------------------------------------------------------
Alright the patch is here (1). What I did is that I based it on {{Predicates}}
guardrail. We have two, warn and fail.
Failure looks like this:
{code}
$ ./bin/cqlsh -u stefan -p stefan
Warning: Using a password on the command line interface can be insecure.
Recommendation: use the credentials file to securely provide the password.
Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
ConnectionException('Failed to initialize new connection to 127.0.0.1:9042:
Error from server: code=2200 [Invalid query] message="Guardrail
minimum_client_driver_version violated: Client driver DataStax Python
Driver:3.29.0 is below required minimum version, connection rejected"')})
<<< here we are back in the console >>>
{code}
I just set minimum version to "3.30.0" to trigger this error.
When it comes to warning, I do not think we can propagate warning back to
client, I am not too strong in this, maybe driver guys will find the way how we
can terminate and still let users know. Otherwise, for now, this is just logged
on server side like this:
{code}
WARN [epollEventLoopGroup-5-4] 2026-03-31T10:49:07,842 NoSpamLogger.java:110 -
Guardrail minimum_client_driver_version violated: Client driver DataStax Python
Driver:3.29.0 is below recommended minimum version
{code}
Configuration-wise it looks like this:
{code}
#minimum_client_driver_versions_warned:
# DataStax Java Driver: "4.18.0"
# DataStax Python Driver: "3.29.0"
#minimum_client_driver_versions_disallowed:
# DataStax Java Driver: "4.0.0"
# DataStax Python Driver: "3.29.0"
{code}
It is basically a map. Keys and values can be whatever. That way, we can
accommodate whatever a driver is reporting as its name without a need to change
server's implementation when some name changes (or new driver is added, or we
start to react on it).
It is using Semver for version logic.
Feedback welcomed!
[~worry] what identifier is used for Go driver? We could add it to
cassandra.yaml as well into that map.
(1) https://github.com/apache/cassandra/pull/4699
was (Author: smiklosovic):
Alright the patch is here (1). What I did is that I based it on {{Predicates}}
guardrail. We have two, warn and fail.
Failure looks like this:
{code}
$ ./bin/cqlsh -u stefan -p stefan
Warning: Using a password on the command line interface can be insecure.
Recommendation: use the credentials file to securely provide the password.
Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
ConnectionException('Failed to initialize new connection to 127.0.0.1:9042:
Error from server: code=2200 [Invalid query] message="Guardrail
minimum_client_driver_version violated: Client driver DataStax Python
Driver:3.29.0 is below required minimum version, connection rejected"')})
<<< here we are back in the console >>>
{code}
I just set minimum version to "3.30.0" to trigger this error.
When it comes to warning, I do not think we can propagate warning back to
client, I am not too strong in this, maybe driver guys will find the way how we
can terminate and still let users know. Otherwise, for now, this is just logged
on server side like this:
{code}
WARN [epollEventLoopGroup-5-4] 2026-03-31T10:49:07,842 NoSpamLogger.java:110 -
Guardrail minimum_client_driver_version violated: Client driver DataStax Python
Driver:3.29.0 is below recommended minimum version
{code}
Configuration-wise it looks like this:
{code}
#minimum_client_driver_versions_warned:
# DataStax Java Driver: "4.18.0"
# DataStax Python Driver: "3.29.0"
#minimum_client_driver_versions_disallowed:
# DataStax Java Driver: "4.0.0"
# DataStax Python Driver: "3.29.0"
{code}
It is basically a map. Keys and values can be whatever. That way, we can
accommodate whatever a driver is reporting as its name without a need to change
server's implementation when some name changes (or new driver is added, or we
start to react on it).
It is using Semver for version logic.
Feedback welcomed!
(1) https://github.com/apache/cassandra/pull/4699
> Guardrail for client driver versions
> ------------------------------------
>
> Key: CASSANDRA-21146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21146
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
> Reporter: Brad Schoening
> Assignee: Stefan Miklosovic
> Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Many application teams lag multiple years behind on Cassandra driver
> upgrades, which increases operational risk and complicates cluster upgrades
> and support. Today, there is no native mechanism to discourage or prevent
> clients from connecting with severely outdated drivers.
> Proposed New Feature
> Introduce an optional server-side guardrail that allows operators to WARN or
> FAIL client connections using drivers older than a configured minimum version
> (for example, rejecting Java drivers earlier than 3.11.5).
> Most environments have just a couple of driver type names (e.g., Java), and
> the guardrail would apply to declared type & version pairs.
> Key Characteristics
> * Disabled by default.
> * Configurable minimum supported driver version, scoped by driver type.
> * Intended primarily for non-production environments (dev / UAT), where
> stricter enforcement can be applied ahead of production rollouts.
> * Provides a clear, early failure signal to application teams that a driver
> upgrade is required.
> Benefits
> * Forces proactive driver upgrades before cluster upgrades.
> * Reduces risk from unsupported or poorly tested legacy drivers.
> * Improves overall fleet hygiene and operational predictability.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
