[DISCUSSION] CASSANDRA-19001 - JRE vs JDK runtime

[Ekaterina Dimitrova]

Hi everyone,

Some of you remember that Paulo raised a concern around warnings about
missing modules on startup during the 5.0 alpha2 voting.[1]
We opened the ticket CASSANDRA-19001. The problem turned out to be not a
5.0 one.
Those modules are missing when we run Cassandra on JRE. Those warnings
happened to appear only when using Java 17. However, the modules are also
missing with Java 11…

jdk. attach is needed for nodetool sjk hh. When someone tries to use
that command, they get an error that JDK is expected. There isn't
anything to do about that here.


Now, the potential issue comes with jdk.compiler. It was added for
Chronicle queues as per this article -
https://chronicle.software/chronicle-support-java-17/

I tried contacting the project to understand the implications of
missing this module - errors expected/degraded performance. I did not
get any response so far. More details on the ticket. (CASSANDRA-19001)


In the meantime, a discussion of whether we want to recommend using
JRE and not JDK started on the ticket. For more details, please check
CASSANDRA-19001.


FQL and Audit Logging use Chronicle Queues. Our CI does not show any
issues when I remove the add-opens/add-exports for jdk.compiler, but
that doesn't mean there is no hidden issue, as we all know.


Naturally, I have a few questions for you:

1) Does Anyone have more experience with Chronicle queues and have
some thoughts/advice to share? Is it worth it to dig more into the
Chronicle repos ourselves?

2) Do we want to recommend people to switch to JDK? Or should we warn
that JDK is recommended on startup if someone has enabled Audit
Logging/FQL and is using JRE? These are some of the options so far
mentioned on CASSANDRA-19001. What we decide will also influence the
response to 1) (Is it worth it to dig more into the Chronicle repos
ourselves?).


A few notes:

- our CI tests with JDK

- our packages check JRE

- the official docker image has used JRE for years

- our docs are inconsistent when mentioning JDK and JRE in different places


https://lists.apache.org/thread/sb3qfmgfx9hpbm58jfo83qsdsxqpqscx

Re: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API

[Jake Luciani]

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
 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 
> Sent: Friday, November 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 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  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%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL

Cassandra Summit: Early registration discount ends tomorrow

[Patrick McFadin]

Hi everyone,

If you've registered for Cassandra Summit, then ignore this email.

If not! Time to get moving. The deadline ends tomorrow.

Link to register:
https://events.linuxfoundation.org/cassandra-summit/register/

Discount code: 23CS20 (Yes you can use it with the early registration price)

If you need motivation, look at this schedule!
https://events.linuxfoundation.org/cassandra-summit/program/schedule/

Let's get everyone gathered! This is our time!

Patrick

Re: [EXTERNAL] Re: [DISCUSSION] CEP-38: CQL Management API

[German Eichberger via dev]

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 
Sent: Friday, November 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 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  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