[
https://issues.apache.org/jira/browse/CASSANDRA-21146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069615#comment-18069615
]
Andy Tolbert commented on CASSANDRA-21146:
------------------------------------------
Agreed, DataStax lineaged drivers and GoCQL have been quite good at reporting
this data as long as the version is ~5 years.
> I just do not know how safe it is to parse versions.
Yes, this may vary from driver to driver and might be difficult unless we have
a way of expressing version patterns, or just enforcing some kind of version
format (of which we can find what the existing popular drivers all incidentally
conform to).
Clients that don't report can be treated as 'unknown' and would be good to have
the capability to treated as unsupported (or not).
I've had a few campaigns where we used client_stats virtual table data to gauge
whether or not a change we were rolling out would impact customers. We also
have some guardrails in our automation where if we detects clients lose
connectivity that we halt upgrades and having that data has been really useful.
One thing that may be nice to do here, or in a separate JIRA, is emit more
client data to audit logs including driver details.
> 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: Rishabh Saraswat
> Priority: Normal
>
> 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]
