Re: Default sorting in nodetool status CASSANDRA-20104

[Abe Ratnofsky]

Looks like we’re moving towards supporting JSON output for nodetool commands:CASSANDRA-12698 (status)CASSANDRA-19771 (gcstats)Is it nodetool’s responsibility to provide sort order flags, when tools like jq exist?

Re: Default sorting in nodetool status CASSANDRA-20104

[Štefan Miklošovič]

I want to add that I slightly prefer ordering by ID because for cases when
a cluster is deployed in a cloud environment, IP addresses assigned to
nodes are basically random so their sorting does not give any meaningful
advantage. In that case, sorting by ID would just order them by their
"age".

On Fri, Dec 13, 2024 at 1:41 PM Štefan Miklošovič 
wrote:

> Hello,
>
> I am reviewing a patch which enables sorting of nodetool's output (in
> ascending and descending direction) for every column. The rationale behind
> it is in (2).
>
> My question is, what should we sort by default? The patch does not impose
> any sorting, by default, it will be just as it is now.
>
> I think that it would be nice if the output is sorted already in some
> manner. The most obvious candidates are either ip (ip address or hostnames)
> or id (uuid).
>
> What is nice about sorting by ID is that I think that TCM introduced
> somewhat predictable node ids where every new node has ID increased by 1.
> So, default sorting by ID in ascending direction would give us the oldest
> node in a cluster as the first one in the output.
>
> On the other hand, sorting by IP addresses would give us nodes with
> lexicographically "lowest ip" as first. These also happen to be the oldest
> / first deployed.
>
> What preference do you have in this matter?
>
> Thanks
>
> (1)
> https://github.com/instaclustr/cassandra/commit/e952524f6becc9f047769a886004b8c1bf5c256d
> (2) https://issues.apache.org/jira/browse/CASSANDRA-20104
>

Re: Default sorting in nodetool status CASSANDRA-20104

[Chris Lohfink]

In the case of not using vnodes, sorting by token would be ideal.

Chris

On Fri, Dec 13, 2024 at 6:52 AM Štefan Miklošovič 
wrote:

> I want to add that I slightly prefer ordering by ID because for cases when
> a cluster is deployed in a cloud environment, IP addresses assigned to
> nodes are basically random so their sorting does not give any meaningful
> advantage. In that case, sorting by ID would just order them by their
> "age".
>
> On Fri, Dec 13, 2024 at 1:41 PM Štefan Miklošovič 
> wrote:
>
>> Hello,
>>
>> I am reviewing a patch which enables sorting of nodetool's output (in
>> ascending and descending direction) for every column. The rationale behind
>> it is in (2).
>>
>> My question is, what should we sort by default? The patch does not impose
>> any sorting, by default, it will be just as it is now.
>>
>> I think that it would be nice if the output is sorted already in some
>> manner. The most obvious candidates are either ip (ip address or hostnames)
>> or id (uuid).
>>
>> What is nice about sorting by ID is that I think that TCM introduced
>> somewhat predictable node ids where every new node has ID increased by 1.
>> So, default sorting by ID in ascending direction would give us the oldest
>> node in a cluster as the first one in the output.
>>
>> On the other hand, sorting by IP addresses would give us nodes with
>> lexicographically "lowest ip" as first. These also happen to be the oldest
>> / first deployed.
>>
>> What preference do you have in this matter?
>>
>> Thanks
>>
>> (1)
>> https://github.com/instaclustr/cassandra/commit/e952524f6becc9f047769a886004b8c1bf5c256d
>> (2) https://issues.apache.org/jira/browse/CASSANDRA-20104
>>
>

Default sorting in nodetool status CASSANDRA-20104

[Štefan Miklošovič]

Hello,

I am reviewing a patch which enables sorting of nodetool's output (in
ascending and descending direction) for every column. The rationale behind
it is in (2).

My question is, what should we sort by default? The patch does not impose
any sorting, by default, it will be just as it is now.

I think that it would be nice if the output is sorted already in some
manner. The most obvious candidates are either ip (ip address or hostnames)
or id (uuid).

What is nice about sorting by ID is that I think that TCM introduced
somewhat predictable node ids where every new node has ID increased by 1.
So, default sorting by ID in ascending direction would give us the oldest
node in a cluster as the first one in the output.

On the other hand, sorting by IP addresses would give us nodes with
lexicographically "lowest ip" as first. These also happen to be the oldest
/ first deployed.

What preference do you have in this matter?

Thanks

(1)
https://github.com/instaclustr/cassandra/commit/e952524f6becc9f047769a886004b8c1bf5c256d
(2) https://issues.apache.org/jira/browse/CASSANDRA-20104

Re: Default sorting in nodetool status CASSANDRA-20104

[Jordan West]

I don’t have a strong preference. I agree with Chris that for those
clusters not using vnodes, by token is nice. Not sure if it’s worth having
the branching for that or just pick some other default and let people use
the sort flags to sort by token when applicable.

Jordan

On Fri, Dec 13, 2024 at 04:53 Chris Lohfink  wrote:

> In the case of not using vnodes, sorting by token would be ideal.
>
> Chris
>
> On Fri, Dec 13, 2024 at 6:52 AM Štefan Miklošovič 
> wrote:
>
>> I want to add that I slightly prefer ordering by ID because for cases
>> when a cluster is deployed in a cloud environment, IP addresses assigned to
>> nodes are basically random so their sorting does not give any meaningful
>> advantage. In that case, sorting by ID would just order them by their
>> "age".
>>
>> On Fri, Dec 13, 2024 at 1:41 PM Štefan Miklošovič 
>> wrote:
>>
>>> Hello,
>>>
>>> I am reviewing a patch which enables sorting of nodetool's output (in
>>> ascending and descending direction) for every column. The rationale behind
>>> it is in (2).
>>>
>>> My question is, what should we sort by default? The patch does not
>>> impose any sorting, by default, it will be just as it is now.
>>>
>>> I think that it would be nice if the output is sorted already in some
>>> manner. The most obvious candidates are either ip (ip address or hostnames)
>>> or id (uuid).
>>>
>>> What is nice about sorting by ID is that I think that TCM introduced
>>> somewhat predictable node ids where every new node has ID increased by 1.
>>> So, default sorting by ID in ascending direction would give us the oldest
>>> node in a cluster as the first one in the output.
>>>
>>> On the other hand, sorting by IP addresses would give us nodes with
>>> lexicographically "lowest ip" as first. These also happen to be the oldest
>>> / first deployed.
>>>
>>> What preference do you have in this matter?
>>>
>>> Thanks
>>>
>>> (1)
>>> https://github.com/instaclustr/cassandra/commit/e952524f6becc9f047769a886004b8c1bf5c256d
>>> (2) https://issues.apache.org/jira/browse/CASSANDRA-20104
>>>
>>

Re: Default sorting in nodetool status CASSANDRA-20104

[Jordan West]

I think it’s good we have a yaml/json option but don’t think that rules out
having sorting when not using that output type.

Jordan

On Fri, Dec 13, 2024 at 15:26 Abe Ratnofsky  wrote:

> Looks like we’re moving towards supporting JSON output for nodetool
> commands:
>
> CASSANDRA-12698 
>  (status)
> CASSANDRA-19771 
>  (gcstats)
>
> Is it nodetool’s responsibility to provide sort order flags, when tools
> like jq exist?
>
>

Re: [DISCUSS] Deprecation of IEndpointSnitch (CASSANDRA-19488)

[guo Maxwell]

Hi All ,
I tested the AlibabaCloudSnitch、 AlibabaCloudLocationProvider together
with NetworkTopologyProximity/NoOpProximity
under Alibaba cloud's environment, region : c-hangzhou-b.
I builded the package using Sam's final PR and deployed three Cassandra
nodes, my test cases are :
1、node joing/decommission;
2、create keyspace and table then doing some insert and select;
3、nodetool ring/status/cms；
All results are correct, the dc is c-hangzhou, rack is : b
Thanks Sam !

guo Maxwell  于2024年12月12日周四 21:47写道：

> Hi sam
> I can help with the validation of AlibabaCloudSnith.
>
> Sam Tunnicliffe 于2024年12月12日 周四下午9:20写道：
>
>> This patch is probably now ready to merge, having been through several
>> iterations of review and with green CI. Before that though, I just want to
>> send one more reminder about it. We've endeavoured to preserve all existing
>> behaviour and to keep configuration 100% backwards compatible. However,
>> some areas have had minimal testing in real clusters, specifically the
>> various cloud platform configurations:
>>
>> * Ec2Snitch/Ec2MultiRegionSnitch
>> * AzureSnitch
>> * AlibabaCloudSnitch
>> * GoogleCloudSnitch
>> * CloudstackSnitch
>>
>> Any help in validating these in their native environments would be
>> welcome.
>>
>> The other consideration is toward custom snitch implementations. The
>> intention is that these should continue to work without interruption or
>> intervention, unless they're leaning heavily on C* internals in which case
>> any changes required ought to be minimal. So it would be great if anyone
>> using a custom snitch implementation is able to check it out and help
>> verify that.
>>
>>
>> > On 31 Oct 2024, at 16:53, Sam Tunnicliffe  wrote:
>> >
>> > Since CEP-21, the source of truth for topology info (a node's
>> datacenter & rack) is ClusterMetadata. Each node provides its dc/rack when
>> it registers itself with the cluster prior to joining and this information
>> is effectively immutable (for now). This significantly reduces the scope of
>> IEndpointSnitch's responsibilities and CASSANDRA-19488 proposes a
>> refactoring which breaks out the remaining functionality into a handful of
>> new providers (full details can be found in the JIRA).
>> >
>> > This is one of the more widely used extension points in Cassandra, so
>> we wanted to bring it to the mailing list in addition to discussing on
>> JIRA.
>> >
>> > To be clear, no operator intervention should be necessary when
>> upgrading. To ease migration onto the new config and to allow us to
>> deprecate snitches in a controlled way, it will remain fully supported to
>> configure nodes using the endpoint_snitch setting in yaml. A SnitchAdapter
>> acts as a facade in this case, presenting the new interfaces to calling
>> code while delegating to the legacy snitch. Most of the in-tree snitches
>> have been refactored to extract implementations of the new interfaces so
>> that their functionality can be used via the new configuration.
>> >
>> > Some questions for the list:
>> >
>> > * We have added 2 new methods to IEndpointSnitch, which have
>> essentially been pulled up from Ec2MultiRegionSnitch and
>> GossipingPropertyFileSnitch to support ReconnectableSnitchHelper.
>> Currently, these are added as default methods on the interface so that
>> out-of-tree snitches remain binary compatible. However, it would be safer
>> to break binary compatibility in this case to ensure that any custom
>> snitches out in the wild must be updated and their behaviour is preserved.
>> So the question is, would there be objections to extending the (now
>> deprecated) IEndpointSnitch interface in this way?
>> >
>> > * Python dtests and config are currently unchanged (aside from some
>> error message checks) so these are exercising the path whereby the clusters
>> are configured with endpoint_snitch and make use of the compatibility
>> adapter. In-jvm upgrade dtests switch from old to new style configuration
>> on upgrade to 5.1 (though in truth, these don't exercise snitches much at
>> all as a special dtest snitch is used throughout). cassandra-latest.yaml
>> contains the new settings, while cassandra.yaml and the variations in
>> test/conf retain the old style settings. How should we approach updating
>> these configs so that we maintain a balance between test coverage,
>> compatibility during upgrades and encouraging the use of new style config
>> in fresh clusters?
>> >
>>
>>

JDK 24 Feature Freeze | Permanently Disabling the Security Manager

[David Delabassee via dev]

Welcome to the final OpenJDK Quality Outreach update of 2024!

JDK 24, scheduled for General Availability on March 18, 2025 [1], is now in 
Rampdown Phase One (RDP1) [2]. At this point, the overall JDK 24 feature set is 
frozen and only low-risk enhancements might still be considered. You will find 
below the final list of the 24 JEPs that were integrated into JDK 24 as well as 
JDK 24 technical materials in the last section.

This QO update also covers 3 important heads-ups related to security, integrity 
and JDK 24.

The next key milestone is early February with the first JDK 24 Release 
Candidate builds. That means that we have a few weeks, modulo the end of year 
break, to find and hopefully address any issue that your projects might 
encounter. So, please let us know if you encounter any issue with the JDK 
early-access builds.

[1] https://openjdk.org/projects/jdk/24/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2024-December/009672.html


# Heads-up - JDK 24: Permanently Disabling the Security Manager

Introduced to enforce the principle of the least privilege, the Security 
Manager was designed to prevent unauthorized code from accessing sensitive 
resources (ex. files, network connections, etc.). While effective in theory, it 
has fallen short in practice for multiple reasons: complexity, limited 
adoption, maintenance overhead and evolving threat landscape.

In Java 17, the Security Manager was deprecated for removal under JEP 411 [3]. 
In JDK 24, its functionality will be effectively disabled via JEP 486 [4]. Key 
changes include:

- Disabling the Security Manager - it will no longer be possible to enable the 
SM at startup using command-line options, nor will it be possible to install a 
custom SM during runtime.
- Rendering the Security Manager API non-functional - the SM API will remain 
present for compatibility but will no longer have any operational effect.
- Improving maintainability - thousands of lines of code dedicated to 
supporting the Security Manager will be removed, freeing OpenJDK contributors 
to implement modern security features.

Developers and enterprises using older Java versions or legacy applications 
relying on the Security Manager will retain access until JDK 24. Beyond that, 
they are encouraged to transition to alternative sandboxing and API 
interception mechanisms.

## Call to Action

The deprecation of the Security Manager in JDK 17 had little to no impact on 
most Java developers. Warnings issued in JDK 17–23 generated minimal discussion 
in the Java ecosystem, highlighting its limited relevance. Furthermore, major 
frameworks and tools (ex. Jakarta EE, Ant, Tomcat, etc.) have already removed 
support for the Security Manager, reinforcing the trend.

For applications still dependent on the Security Manager, the JDK offers 
options to identify and address its usage:

- jdeprscan [5] scans a JAR file for the usage of deprecated API elements, and 
it helps find code using these methods.
- Messages on the console warnings highlight Security Manager usage during 
runtime.
- Check how you launch your Java application - with the Security Manager 
allowed or enabled via command line options, or policy files that require it to 
be installed and configured.

These tools give code maintainers the necessary insights to transition away 
from the Security Manager before its complete removal in future JDK releases. 
By taking these steps, you will ensure a smooth transition from the Security 
Manager while adopting more effective security practices.

This is a summary; for more details, make sure to read JEP 486 [4].

[3] https://openjdk.org/jeps/411
[4] https://openjdk.org/jeps/486
[5] https://dev.java/learn/jvm/tools/core/jdeprscan/


# Heads-up - JDK 24: Prepares Restricted Native Access

Any interaction between Java code and native code, be it via the Java Native 
Interface (JNI) API or the Foreign Function & Memory (FFM) API, is risky in the 
sense that it can compromise the integrity of applications and of the Java 
Platform itself, for example by causing JVM crashes, even after the native code 
completed execution. According to the policy of integrity by default, all JDK 
features that are capable of breaking integrity must obtain explicit approval 
from the application’s developer. JDK 24, by means of JEP 472 [6], prepares 
that by aligning the behaviors of JNI and FFM by:

- Printing warnings for all restricted operations (with the goal to turn these 
into exceptions in a future release).
- Expanding the command-line options `--enable-native-access` and 
`--illegal-native-access` to govern restricted operations of both APIs.

Note that this is a change for JNI, which used to not trigger such warnings, as 
well as for FFM, which used to forbid restricted operations by default. 
Starting with JDK 24, both APIs behave uniformly by printing warnings. In the 
future, both APIs will throw exceptions instead. The intent is neither to 
discourage the use of, deprecate, or eve