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://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API
