Thanks for the inputs Stefan & Francisco! Hope we are good with introducing the changes.
I guess the next step is to make changes and raise a PR, isn't it? Do I have to follow any other procedure (like - voting thread) before making the changes? On Tue, Dec 2, 2025 at 4:43 AM Štefan Miklošovič <[email protected]> wrote: > If you present the reasons like that, I think that including that library > into Sidecar is justifiable. > > On Thu, Nov 20, 2025 at 5:58 AM Venkata Harikrishna Nukala < > [email protected]> 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 >>>>> >>>>
