Hi, I've made a few updates to the design document to reflect the comments we've received. However, the admin port (service port) has not been removed from the document yet, but I think we can do that since it's not necessary for the initial implementation. I also think that the k8ssandra-management-api fits in perfectly into the design that we have. A few notes on both of these topics, read on.
Admin port (Service port) For the initial implementation, a dedicated admin port is not required because these changes do not add any new API consumers. New CQL management operations can be exposed through the standard data ports using the role mode that we already have as an experimental API - the existing tools will continue to work as they do it now: the nodetool and Apache Sidecar via JMX client, and k8ssandra-management-api via unix domain socket. Personally, I like the idea of the admin port, but since it's not needed right now, we can leave the decision for phase 2 of the CEP, e.g. making the `cqlsh / as sysdba` command work also requires some effort. So, I can remove the service port from the basic requirements right now. Wdyt? k8ssandra-management-api I've been poking around the code and I'm really excited about the way how it's implemented and how it uses the Unix domain socket. I really like those sorts of things. The pluggable agent that does the metrics export has already been mentioned as part of another CEP-1 [1], so seeing it as a part of the Apache Cassandra itself that can be reused by other projects makes sense to me. It should also make it easier for C* to add new metrics as we are guaranteed API consistency and bug-free right on the CI of the main project. In general, the k8ssandra can benefit from the design is implemented: 1. As a first step, we can implement a new REST API test adapter for CommandRegistry that exposes available commands and can be used to align our work with all the management endpoints exposed by the k8ssandra. This step doesn't require any changes on the k8ssandra project side. 2. Since the endpoints are statically configured we can change the hardcoded `CALL NodeOps.<>` queries to the real CQLs and remove the query interceptors, as all of them will be available via CQL after the design is implemented (see the diagram in the CEP-38); 3. We can switch from the statically configured endpoints to the dynamically configured ones as all the command metadata are available in the CommandRegistry and don't need to be written in the code beyond the C* itself. Thoughts? [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224#CEP1:ApacheCassandraManagementProcess(es)-metrics On Mon, 20 Nov 2023 at 21:10, Jake Luciani <jak...@gmail.com> wrote: > > Hi, > > I originally worked on the management API sidecar mentioned above. > I'm excited to see there's renewed interest in the cql for ops concept. > > Though it currently uses an agent to inject the local socket for cql > (so it can be used by older versions of Apache Cassandra), > Similar logic like the management api project could be added directly > to C* versions if the sidecar project has picked versions it would > support. > > I think for security reasons and operability the local unix socket is > the cleanest way to support cql as management. > It also works very well for any sidecar to access ops (while not > messing with JMX). > > Let me know if there's anything I can do to help. > > Jake > > On Mon, Nov 20, 2023 at 11:40 AM German Eichberger via dev > <dev@cassandra.apache.org> wrote: > > > > Hi, > > > > From a cloud provider perspective we expose the storage port to customers > > for Hybrid scenarios (e.g. fusing on-prem Cassandra with in-cloud > > Cassandra) so would prefer an extra port or a socket. > > Thanks, > > German > > > > ________________________________ > > From: Dinesh Joshi <djo...@apache.org> > > Sent: Friday, November 17, 2023 4:06 PM > > To: dev <dev@cassandra.apache.org> > > 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 you have this - > > > > > A dedicated admin port with the native protocol behind it, > > > allowing only admin commands, to address the concerns when > > > the native protocol is disabled in certain circumstances > > > e.g. the disablebinary command is executed; > > > > I understand what you're achieve here. However, there are a few reasons we > > should probably offer some choice to our users w.r.t. using a dedicated > > port for management functions. > > > > Today Cassandra exposes several ports - 9042, 9142, 7000 and 7001. The > > sidecar runs on port 9043. Thats a lot of ports. I would prefer to allow > > users to access management functionality over one of the existing ports. > > > > I realize that this would mean a subtle change in behavior for > > disablebinary when we offer it over port 9042 and not when the operator > > decides to use a dedicated port. > > > > More importantly, I think having this functionality exposed over the > > storage ports may be even better. The storage ports are typically > > firewalled off from the end users. Operators and tooling, however, usually > > have access to these ports. This especially makes sense from a security > > standpoint where we'd like to limit users from accessing management > > functionality. > > > > What do others think about this approach? > > > > thanks, > > > > Dinesh > > > > > On Nov 13, 2023, at 10:08 AM, Maxim Muzafarov <mmu...@apache.org> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FCASSANDRA%2FCEP-38%253A%2BCQL%2BManagement%2BAPI&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7C510fbe97b579406b389f08dbe7ca5430%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638358628430485779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aJcomfk5ufDIUqTFmUWzuvR18cFL8qAUS%2F3XwffqVqs%3D&reserved=0 > > > > > -- > http://twitter.com/tjake
