This sounds good to me. Adding an existing approved dependency for Cassandra to Sidecar should be straightforward. The MIT license is compatible with ASF projects that use the artifacts as a dependency.
Best, - Francisco On 2025/11/20 04:56:50 Venkata Harikrishna Nukala wrote: > Thanks for the feedback! > > Running Sidecar without Cassandra might sound pointless, but I think it > makes sense to run Sidecar alone before starting the Cassandra instance for > a short period of time. The pattern I'm looking for is: start the Sidecar, > perform system validations, and then start Cassandra. Starting Cassandra > without performing validations has side effects - it joins gossip and may > start bootstrapping, which are difficult to roll back. > > When Sidecar is up and running, tooling/operators can perform validations > like whether the instance has required disks attached, sufficient disk > capacity, expected memory size, and even network connectivity to > seeds/peers (at least Sidecars). When these validations are done before > starting Cassandra, the tooling can make decisions before the node joins > the ring. > > Querying MBeans requires Cassandra to be running, but by then it has > already joined gossip or started bootstrapping. Taking a step back at this > state is difficult compared to performing validations with Sidecar first, > then starting Cassandra. > > On OSHI usage: I see this as complementary, not duplication - Cassandra > uses OSHI for startup checks, while Sidecar would use it for pre-flight > validation APIs. Different purposes at different lifecycle stages. > > In short: Sidecar enables validation before joining the ring, which MBeans > can't provide. I'm open to alternative approaches if there's a better way > to address this pre-flight validation gap - would love your thoughts! > > On Sun, Nov 16, 2025 at 5:46 PM Venkata Harikrishna Nukala < > [email protected]> wrote: > > > Ahh! Somehow I missed that Cassandra is already using the OSHI dependency. > > I will check and get back to you shortly about the questions. > > > > On Sun, Nov 16, 2025 at 4:38 PM Štefan Miklošovič <[email protected]> > > wrote: > > > >> More context here: > >> > >> https://issues.apache.org/jira/browse/CASSANDRA-16565 > >> > >> On Sun, Nov 16, 2025 at 11:58 AM Miklosovic, Stefan via dev < > >> [email protected]> wrote: > >> > >>> Hi, > >>> > >>> we are using OSHI in Cassandra already. Check for example > >>> org.apache.cassandra.utils.SystemInfo and where it is used. > >>> > >>> I do agree that this library is helpful. However, I think we should > >>> spend some time here to decide if we want to introduce this to Sidecar. > >>> > >>> What I would like to see is to have the current library in Cassandra > >>> utilised way more than it is now and we might just call some MBean method > >>> in Cassandra from Sidecar to get the information and eventually maybe > >>> expose it in the form of an endpoint if required. > >>> > >>> I think that if we enrich current SystemInfo in Cassandra, Cassandra > >>> itself might benefit from it in the future and make decisions based on > >>> that. If we delegate this to Sidecar only then we will lose the ability of > >>> Cassandra to "govern" and inspect the machine it runs at. > >>> > >>> There is nothing wrong with exposing the information Cassandra collected > >>> to Sidecar if Sidecar is interested in it. When Sidecar is running, it > >>> basically needs running Cassandra, running Sidecar alone without Cassandra > >>> is pretty much pointless, if I exaggerate. So there will be always a way > >>> how to get this information from Cassandra, no? > >>> > >>> Regards > >>> > >>> > >>> *From: *Venkata Harikrishna Nukala <[email protected]> > >>> *Date: *Sunday, 16 November 2025 at 10:00 > >>> *To: *[email protected] <[email protected]> > >>> *Subject: *[DISCUSS] Adding oshi-core dependency for system information > >>> to Cassandra Sidecar project > >>> > >>> *EXTERNAL EMAIL - USE CAUTION when clicking links or attachments* > >>> > >>> > >>> > >>> Hi devs, > >>> > >>> I'd like to propose adding the oshi-core library to the Cassandra > >>> Sidecar project for collecting system information. This information can be > >>> useful to operate Cassandra clusters better and can help capacity planning > >>> and operational troubleshooting. With CASSSIDECAR-366 > >>> <https://urldefense.com/v3/__https://issues.apache.org/jira/browse/CASSSIDECAR-366__;!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQzqv2VBkg$>, > >>> proposing > >>> to expose disk information via Sidecar that can help capacity planning. > >>> While CASSSIDECAR-366 focuses on disk metrics as the initial use case, I > >>> believe this dependency provides valuable capabilities we can leverage > >>> over > >>> time. Here are more details > >>> > >>> What is oshi-core? > >>> > >>> OSHI (Operating System and Hardware Information) > >>> <https://urldefense.com/v3/__https://github.com/oshi/oshi__;!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQztLP7L-g$> > >>> is > >>> a cross-platform JNA-based Java library for retrieving system and hardware > >>> information. It does not require the installation of any additional native > >>> libraries and aims to provide a cross-platform implementation to retrieve > >>> information including: > >>> > >>> > >>> - Disk/filesystem metrics (initial use case) > >>> - CPU utilization and load averages > >>> - Memory and swap usage > >>> - Network interface statistics > >>> - Process information > >>> - System uptime and boot time > >>> > >>> > >>> Why oshi-core instead of JDK's FileStore? > >>> > >>> JDK's FileStore API lacks mount point information - you can't tell which > >>> device (/dev/sda1, /dev/nvme0n1) corresponds to each store. This could be > >>> crucial from the operational perspective. This library provides > >>> information that JDK does not provide. > >>> > >>> oshi-core dependency analysis: > >>> > >>> - It supports Linux, MacOS, Windows & UNIX based platforms (AIX, > >>> Solaris, etc...) [ref > >>> > >>> <https://urldefense.com/v3/__https://github.com/oshi/oshi?tab=readme-ov-file*supported-platforms__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQx5cUqaPQ$> > >>> ] > >>> - It internally uses the JNA library to interact with native OS. JNA > >>> supports all major processor architectures including x86, amd64, > >>> aarch64 > >>> and others [ref > >>> > >>> <https://urldefense.com/v3/__https://github.com/java-native-access/jna/blob/0deb54b46dc04f655e3c1d46e848fd26bf47c09a/native/Makefile*L10__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQxqcevCbA$> > >>> ] > >>> - Cassandra is already using the JNA library > >>> - Found that Apache Flink is using oshi-core for system metrics [ref > >>> > >>> <https://urldefense.com/v3/__https://github.com/apache/flink/blob/master/pom.xml*L591__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQx4Ne8MGQ$>] > >>> [ref > >>> > >>> <https://urldefense.com/v3/__https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/metrics/util/SystemResourcesMetricsInitializer.java*L37__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQwGQge3Pg$> > >>> ] > >>> - Uses MIT license > >>> > >>> > >>> I propose we add oshi-core 6.9.1 as a dependency to Sidecar. While we're > >>> starting with disk metrics (CASSSIDECAR-366), this positions us to add > >>> other system information endpoints as operational needs arise. > >>> > >>> Any thoughts or concerns? > >>> > >>> Thanks! > >>> Harikrishna > >>> > >> >
