On 4/8/2025 11:31 PM, Mick Semb Wever wrote:
On Tue, 8 Apr 2025 at 23:59, Joel Shepherd wrote:
I'm curious what the argument for pumping ticket notifications
into #cassandra-dev, etc., is, versus pumping them into a
dedicated channel.
Hi Joel,
for myself, and I'm guess
FWIW, my personal experience is that mixing automated notifications
(beyond a very low volume) with human communications adds a bunch of
noise to the human conversations and increases the risk of an
interesting automated notification being missed (scrolling past them to
get to the meatier human
Related JIRA: https://issues.apache.org/jira/browse/CASSANDRA-20416
Includes links to the draft code and more complete documentation of the
proposed approach.
Thanks -- Joel.
On 3/4/2025 12:48 PM, Joel Shepherd wrote:
Hi - I have a side project that provides client- and node-side Java
plug
On 3/6/2025 7:16 AM, Jon Haddad wrote:
Assuming everything else is identical, might not matter for S3.
However, not every object store has a filesystem mount.
Regarding sprawling dependencies, we can always make the provider
specific libraries available as a separate download and put them on
is moved to object store at
some point, and pulled to the local disk on demand.
I am *firmly* of the position that this CEP should not exclude the
local storage as cache option, and should be accounted for in the design.
Jon
[1] https://issues.apache.org/jira/browse/CASSANDRA-19663
O
vote thread [3].
Cheers,
– Scott
[1] http://issues.apache.org/jira/browse/CASSANDRA
[2] http://issues.apache.org/jira/browse/CASSJAVA
[3]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
On Mar 4, 2025, at 12:48 PM, Joel Shepherd wrote:
Hi - I have a side pro
Hi - I have a side project that provides client- and node-side Java
plug-ins to enable client-to-node authentication based on AWS
identities. This would, for example, enable clients to use EC2 instance
roles to authenticate to Cassandra nodes, or use ordinary IAM
keys/secret keys. The client ne
WITH INDEX (or something equivalent) seems really useful.
Less opinionated on the specific syntax, but I think there is a lot of
value in the form of predictable, controllable performance, in giving
developers more direct control over query execution, whether that's
index selection or even low
hanism for existing clients that don’t try to negotiate. Which means it can
be seamlessly enabled.
-Jeremiah
On Dec 4, 2024, at 5:27 PM, Joel Shepherd wrote:
A negotiating authenticator is appealing, but I'm concerned that it doesn't have a good migration
story. If a client has
as a single authenticator that has separate
configuration of the supported mechanisms. So the single authenticator
maintained is the “negotiating authenticator” which can proxy off to which ever
other mechanisms you want.
On Dec 3, 2024, at 6:37 PM, Joel Shepherd wrote:
I'm interested,
I'm interested, at least in a more narrowly-scoped subset of CEP-31:
authentication negotiation only, configured via YAML (not dynamically),
with CQL integration, proxy authorization, multiple role managers and
new authn mechanisms out of scope.
I've started working through Derek's proposal in
Hi - I've been doing some exploration in Cassandra's client
authentication workflow and got tripped up by surprising (to me)
behavior regarding role name case sensitivity.
I made an implementation of IAuthenticator and SaslNegotiator. After
evaluateResponse(), when the client responds successf
12 matches
Mail list logo
