[
https://issues.apache.org/jira/browse/CASSPYTHON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125562#comment-18125562
]
Bohdan Siryk commented on CASSPYTHON-29:
----------------------------------------
Thanks [~bschoeni] for your feedback! I think you have a point. This is
actually an observability use case after all, so it's enough to have couple of
fields that would be visible in virtual tables and nodetool clientstats like
{*}application_name{*}, *application_version* and {*}client_id{*}. When I was
implementing this I missed the fact that python driver supported it already
just for a different use case and it then got removed.
As you said, what we can do instead is return those 3 fields to a cluster
config and map them to corresponding options in a startup message. It would be
enough to determine relation between specific instance of an application and a
client connection. One thing I'm unsure how would other than Cassandra backends
react to such params? Insight was part of DSE, right? How would newer versions
of DSE respond to this? Will they act the same way as Cassandra does or they
will reject connection?I have naver worked with DSE nor Astra, so I can't tell
how it will behave.
Assuming they behave the same way as Cassandra, then I'm in favor of narrowing
down this to just a set of fields that is enough to identify
application-connection relation.
About security implication, I'm not that concerned actually because it was
documented that those values are visible as client metrics, so anybody who's
access to nodetool / virtual tables can see the values. On the other hand, if
we can prevent this case, why not?
> Allow user to specify arbitrary parameters for STARTUP message
> --------------------------------------------------------------
>
> Key: CASSPYTHON-29
> URL: https://issues.apache.org/jira/browse/CASSPYTHON-29
> Project: Apache Cassandra Python driver
> Issue Type: Improvement
> Components: Core
> Reporter: Swathi Sekar
> Assignee: Bohdan Siryk
> Priority: Normal
> Fix For: 4.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Modify the driver to allow sending arbitrary STARTUP message options.
> Proposed design:
> - Add `extra_startup_options` param to Cluster constructor.
> - Thread it through Cluster -> connection setup (cluster.py) ->
> StartupMessage.
> - Define clear precedence/conflict behavior when duplicate/conflicting
> options are passed into the StartupMessage constructor.
> *Note:*
> This Jira was originally created for sending the client's application name
> and version as `APPLICATION_NAME` /
> `APPLICATION_VERSION` options in the STARTUP message, which is tied to the
> now-defunct DataStax Insights offering.
> Since the Java driver (5.0.0) and eventually C/C++ driver (3.0.0) are
> removing withApplicationName()/withApplicationVersion() entirely, this ticket
> has been updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
