Right, sounds fair. On Mon, Dec 8, 2025 at 5:04 PM Štefan Miklošovič <[email protected]> wrote:
> 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 >>>>>>> >>>>>>
