Jon,
That sounds good. Let's make these commands rely on the settings
virtual table and keep the initial changes as minimal as possible.
We've also scheduled a Cassandra Contributor Meeting on January 30th
2024, so I'll prepare some slides with everything we've got so far and
try to prepare
It's great to see where this is going and thanks for the discussion on the
ML.
Personally, I think adding two new ways of accomplishing the same thing is
a net negative. It means we need more documentation and creates
inconsistencies across tools and users. The tradeoffs you've listed are
worth
> Some operations will no doubt require a stored procedure syntax, but perhaps
> it would be a good idea to split the work into two:
These are exactly the first steps I have in mind:
[Ready for review]
Allow UPDATE on settings virtual table to change running configurations
Ugh, I moved some stuff around and 2 paragraphs got merged that shouldn't
have been.
I think there's no way we could rip out JMX, there's just too many benefits
to having it and effectively zero benefits to removing.
Regarding disablebinary, part of me wonders if this is a bit of a hammer,
and
> Syntactically, if we’re updating settings like compaction throughput, I
would prefer to simply update a virtual settings table
> e.g. UPDATE system.settings SET compaction_throughput = 128
I agree with this, sorry if that wasn't clear in my previous email.
> Some operations will no doubt
Syntactically, if we’re updating settings like compaction throughput, I would
prefer to simply update a virtual settings table
e.g. UPDATE system.settings SET compaction_throughput = 128
Some operations will no doubt require a stored procedure syntax, but perhaps it
would be a good idea to
> Fundamentally, I think it's better for the project if administration is fully
> done over CQL and we have a consistent, single way of doing things.
Strongly agree here. With 2 caveats:
1. Supporting backwards compat, especially for automated ops (i.e. nodetool,
JMX, etc), is crucial.
I like the idea of the ability to execute certain commands via CQL, but I
think it only makes sense for the nodetool commands that cause an action to
take place, such as compact or repair. We already have virtual tables, I
don't think we need another layer to run informational queries. I see
Happy New Year to everyone! I'd like to thank everyone for their
questions, because answering them forces us to move towards the right
solution, and I also like the ML discussions for the time they give to
investigate the code :-)
I'm deliberately trying to limit the scope of the initial solution
Adding to Hari's comments:
> Any changes expected at client/driver side? While using JMX/nodetool, it is
> clear that the command/operations are getting executed against which
> Cassandra node. But a client can connect to multiple hosts and trigger
> queries, then how can it ensure that
Hi Maxim,
I think this CEP is a great start to viewing Cassandra operations in a
different way! However, I have a few questions about it.
- How are the results of the commands expressed to the CQL client? Since
the command is being treated as CQL, I guess it will be rows, right? If
yes,
Hi Maxim,
I'm part of the K8ssandra team and am very happy to hear that you like our
management API design.
Looking at the CEP, I see that your current target design mentions the
k8ssandra-management-api.
What do you have in mind specifically there? Do you plan on rewriting a
brand new
Hi Maxim,
Thanks for working on this CEP!
The CEP addresses some of the features we have been discussing for Cassandra
Sidecar. For example, a dedicated admin port, moving towards more CQL-like
interfacing with Cassandra, among others.
I think virtual tables intended to bring the gap down
> > ________________
> > From: Dinesh Joshi
> > Sent: Friday, November 17, 2023 4:06 PM
> > To: dev
> > Subject: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API
> >
> > Hi Maxim,
> >
> > Thanks
-prem Cassandra with in-cloud Cassandra) so
> would prefer an extra port or a socket.
> Thanks,
> German
>
>
> From: Dinesh Joshi
> Sent: Friday, November 17, 2023 4:06 PM
> To: dev
> Subject: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Managemen
vember 17, 2023 4:06 PM
To: dev
Subject: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API
Hi Maxim,
Thanks for putting this CEP together! This is a great start. I have gone over
the CEP and there is one thing that stuck out to me.
Among the 'basic requirements', I see
Hi Maxim,
Thanks for putting this CEP together! This is a great start. I have gone over
the CEP and there is one thing that stuck out to me.
Among the 'basic requirements', I see you have this -
> A dedicated admin port with the native protocol behind it,
> allowing only admin commands, to
other means but I can also see this as an adjacent
> sub project - let's discuss
>
> German
>
>
> From: Maxim Muzafarov
> Sent: Monday, November 13, 2023 10:08 AM
> To: dev@cassandra.apache.org
> Subject: [EXTERNAL] [DISCUSSION]
: dev@cassandra.apache.org
Subject: [EXTERNAL] [DISCUSSION] CEP-38: CQL Management API
Hello everyone,
While we are still waiting for the review to make the settings virtual
table updatable (CASSANDRA-15254), which will improve the
configuration management experience for users, I'd like to take
another step fo
Hello everyone,
While we are still waiting for the review to make the settings virtual
table updatable (CASSANDRA-15254), which will improve the
configuration management experience for users, I'd like to take
another step forward and improve the C* management approach we have as
a whole. This
20 matches
Mail list logo
