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
