The fact o3 used "Bus-factor" as a dimension is just amazing. After reading more about the project, the possibilities are pretty interesting. I suspect we'll see this in a Haddad talk soon.
On Fri, Jun 13, 2025 at 1:57 AM Josh McKenzie <jmcken...@apache.org> wrote: > I was curious if o3 (model from OpenAI) would be able to do a deep dive > health check on a repo to assist in considering taking it as a dependency. > The results can be found here: > https://chatgpt.com/share/684be703-1d4c-8002-b831-f997f829f4b4 > > Apparently it can, and can do it quite well. This was a useful time saver > (and honestly did a better job than I usually can in > 10x the time) > > I'm +1 to taking this as a dependency on the lib in core C*. The rest of > the ecosystem can consume it (more easily if we move to a cassandra-shared > regime shared library build as well), and it opens up some interesting > opportunities for us in both how we test core C* proper and what we expose > in tooling. > > On Thu, Jun 12, 2025, at 7:36 PM, Paulo Motta wrote: > > I'd prefer to avoid calling an external process and use the library if > possible. Not sure about including it in the project by default, but also > not against. > > If there's contention about including it, I wonder if it would make sense > to explore java's optional module extension[1] to make this available > optionally ? I can see this being useful for other extensions if we haven't > explored that option. > > Then we could have another project cassandra-sidecar-extensions (or > similar) that would be linked by sidecar/advanced operators to enable > extended featureset in the main process. > > > [1] - > https://openjdk.org/projects/jigsaw/doc/topics/optional.html > > On Thu, 12 Jun 2025 at 17:57 Doug Rohrer <droh...@apple.com> wrote: > > Hey folks! > > We're looking into enabling the sidecar to collect async profiles from > Cassandra and, digging through the async-profiler code and usage, it seems > like there may be a few different ways to do it. I’m curious if other folks > have already done this beyond just “run asprof with the pid of the > Cassandra process”, as I’m a bit hesitant to depend on executing an > external process from the Sidecar to gather the actual profile if we can > avoid it. > > There seem to be some opportunities to integrate the profiler into another > project (see > https://github.com/async-profiler/async-profiler/blob/master/docs/IntegratingAsyncProfiler.md#using-java-api) > but it seems this would end up having to be part of Cassandra, and somehow > callable via the sidecar (JMX? Some virtual table interface where you > insert a row to start a profile with the profiler options, and it kicks off > the profile, dumping the results into the table when it’s done?). > > The benefit in putting this functionality into Cassandra would be that > other consumers (in-jvm dtests, python dtests, other monitoring systems > where Sidecar isn’t available, easy-cass-lab) would be able to leverage the > same interface rather than having to re-invent the wheel each time. > > Drawback is it’s another library, and one with native library > dependencies, added to the class path and loaded at runtime. > > Thoughts? Previous experiences (good or bad)? > > Thanks, > > Doug > > >
