Usage of Log Detective for openSUSE

[danigm]

Log Detective looks like a great project! At openSUSE we are thinking about the possibility of use it or integrate it with open build service.

I've proposed a GSoC project to research the different possibilities of integrating or using log-detective in openSUSE development.

Do you think it's interesting to submit logs from build.opensuse.org directly to https://log-detective.com/ or it could be better to think about a custom deployment for a specific trained LLM for openSUSE?

Everything is RPM so logs could be very similar, but the build tooling is different so I'm not sure if it could be better to have more "varied" data from different projects or if it's better to have different instances.

[xsuchy]

I think the variety will be helpful. Feel free to submit it here. If you will need any assistance or have question feel free to raise it.

[TomasTomecek]

Agreed with @xsuchy

For generic use cases we can totally share the data set because the solutions will be very similar. The model should also take into account that the specific build is happening in Fedora, CentOS Stream, or OpenSUSE and tailor the answer.

[aazam-gh]

@TomasTomecek When submitting a log from build.opensuse.org, is it better to specify that is a log from openSUSE when annotating? (i.e mentioning it as a snippet?)

[TomasTomecek]

@aazam-gh absolutely! That way we can teach the LLM to associate openSUSE specific patterns in logs with your ecosystem.

[aazam-gh]

Hello @TomasTomecek @xsuchy I will be working on researching ways to integrate the log detective model with openSUSE as part of GSOC 25
I can see the current log level is at 86%, I assume when it reaches 100%, we would still continue to feed logs to it?

[TomasTomecek]

happy to hear about your work, please keep us updated

We are at 100% right now and we still want more. The 100% just means that now have enough data to start doing meaningful research in integrating it into our workflow.

[aazam-gh]

Hi @TomasTomecek currently we have this repo for scripts, research and analyzing logs. One of the main drawbacks with using the log detective api is the long wait times to receive a response.
As an alternative, I was running log detective locally which allowed for faster inferences.
However, I would like to know, is the local model up-to-date and utilizing the training logs?

[TomasTomecek]

@aazam-gh wow, truly impressive!!

As an alternative, I was running log detective locally which allowed for faster inferences.

100%, our deployment doesn't scale (we are using the cheapest AWS nvidia GPU right now) so it can easily take a few minutes to get an answer, deploying the service yourself is highly recommended

However, I would like to know, is the local model up-to-date and utilizing the training logs?

@jpodivin is working on finetuning a model literally right now; by default we are still on stock mistral 0.2 but you can easily swap it in your deployment for something better, here's an analysis of different models we did a month ago: https://fedora-copr.github.io/posts/logdetective-model-analysis

[jpodivin]

@aazam-gh Local deployment is the best option. The compose file we have in our primary repo https://github.com/fedora-copr/logdetective/ can serve a blueprint for that. Out of the box it gives you Log detective server, LLM server (llama.cpp) with GPU support to run inference on and a database to track requests. Depending on resources available you may want to swap the llama.cpp based server for vLLM or even 3rd party service like OpenAI. As long as the server supports OpenAI chat API, the Log Detective can work with it.