I do not think that we need to vote on this. Everybody presumably reads the ML and this was long enough up to react to that and reject the idea. I think that at this point it would be just an unnecessary ceremony to go through, even more so once the library you want to introduce was already introduced in Cassandra itself so I guess its usage at other places is warranted as well.
On Thu, Dec 4, 2025 at 6:48 PM Venkata Harikrishna Nukala < [email protected]> wrote: > 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 >>>>>> >>>>>
