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, some of the nodetool commands output are a bit hierarchical in nature (e.g. cfstats, netstats etc...). How are these cases handled? - 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 commands are executed against the desired Cassandra instance? - The term COMMAND is a bit abstract I feel (subjective). Some of the examples quoted are referring to updating settings (for example: EXECUTE COMMAND setconcurrentcompactors WITH concurrent_compactors=5;) and some are referring to operations. Updating settings and running operations are considerably different things. They may have to be handled in their own way. And I also feel the settings part is overlapping with virtual tables. If virtual tables support writes (at least the settings virtual table), then settings can be updated using the virtual table itself. - How are the responses of different operations expressed through the Command API? If the Command Registry Adapters depend upon the command metadata for invoking/validating the command, then I think there has to be a way for them to interpret the response format also, right? Thanks! Hari On Wed, Nov 29, 2023 at 12:55 AM Alexander DEJANOVSKI <adejanov...@gmail.com> wrote: > 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 implementation which would be partially inspired by our agent? Or > would the project integrate our agent code in-tree or as a dependency? > The latter would require of course changes to remove the CQL interceptor > and run the queries naturally against Cassandra, along with extracting just > the agent without the REST server. > The former suggests that we'd have to modify our REST server to interact > with the newly developed agent from the Cassandra project. > > For the metrics, we were using MCAC > <https://github.com/datastax/metric-collector-for-apache-cassandra> so > far in the K8ssandra project but the use of collectd (while very convenient > for non kubernetes use cases) and the design issues it created led us to > build a metrics endpoint directly into the management api which hooks on to > the metrics registry, and is out of the box scrapable by Prometheus. As you > mentioned, it also allows us to extend the set of metrics easily, which > we've done recently to expose running compactions and streams as metrics. > It is also very efficient compared to JMX based alternatives. > > Let us know how we can help move this CEP forward as we're willing to > participate. > I think it would be great to have a single api that could be used by all > sidecars, may they be custom or officially supported by the project. > > Cheers, > > Alex > > Le mar. 28 nov. 2023 à 01:00, Francisco Guerrero <fran...@apache.org> a > écrit : > >> 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 between JMX and >> CQL. However, virtual tables cannot action on node operations, so CEP-38 is >> finally addressing that gap. >> >> I look forward to collaborating in this CEP, I think Cassandra and its >> ecosystem will greatly benefit from this enhancement. >> >> Best, >> - Francisco >> >> On 2023/11/13 18:08:54 Maxim Muzafarov wrote: >> > 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 approach aims to make all Cassandra management commands >> > accessible via CQL, but not only that. >> > >> > The problem of making commands accessible via CQL presents a complex >> > challenge, especially if we aim to minimize code duplication across >> > the implementation of management operations for different APIs and >> > reduce the overall maintenance burden. The proposal's scope goes >> > beyond simply introducing a new CQL syntax. It encompasses several key >> > objectives for C* management operations, beyond their availability >> > through CQL: >> > - Ensure consistency across all public APIs we support, including JMX >> > MBeans and the newly introduced CQL. Users should see consistent >> > command specifications and arguments, irrespective of whether they're >> > using an API or a CLI; >> > - Reduce source code maintenance costs. With this new approach, when a >> > new command is implemented, it should automatically become available >> > across JMX MBeans, nodetool, CQL, and Cassandra Sidecar, eliminating >> > the need for additional coding; >> > - Maintain backward compatibility, ensuring that existing setups and >> > workflows continue to work the same way as they do today; >> > >> > I would suggest discussing the overall design concept first, and then >> > diving into the CQL command syntax and other details once we've found >> > common ground on the community's vision. However, regardless of these >> > details, I would appreciate any feedback on the design. >> > >> > I look forward to your comments! >> > >> > Please, see the design document: CEP-38: CQL Management API >> > >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API >> > >> >
