Fetching the latest programs, projects, and workspace data.

Makers' choice for sysadmins, developers & users
Showing 5 of 44 projects. Click any project card for scope, mentors, and proposal studio.
Mentors: Student: AkashKumar
I propose to build a reproducible benchmark framework for evaluating cloud-native storage options for Uyuni on RKE2. The problem is that different Kubernetes storage backends can behave very differently for the kinds of operations Uyuni depends on, especially PostgreSQL transactions, repository metadata handling, and package distribution. The project will address this by starting from a storage-only control baseline and then extending the evaluation into PostgreSQL benchmarking and Uyuni-specific workload benchmarking, while collecting synchronized observability data for each run. The same benchmark method will be reused across selected storage backends so that results remain comparable and can support a practical recommendation for which StorageClass Uyuni should support on RKE2. The main deliverables will be a reusable benchmark harness, benchmark results for the tested storage backends, PostgreSQL and Uyuni workload comparison data, observability-backed summaries, and a final report that explains the benchmark method, compares the backends, and recommends the most suitable StorageClass. The project will also produce the configuration artifacts and scripts needed to rerun the benchmark process and reproduce the tested setup.
Mentors: Student: Geetansh Goyal
Uyuni is a powerful systems management platform, but today it lacks a native way to automate actions based on events in real time. As a result, administrators often have to write custom scripts to react to things like patch updates or system changes, which adds unnecessary complexity and effort. This project aims to change that by introducing a simple, scalable event-driven architecture that turns Uyuni into an automation-friendly platform. The idea is to make it easy for administrators to connect Uyuni with other tools and build workflows without writing a lot of custom code. The solution has two main parts. First, an MQTT-based event publisher that hooks into Uyuni’s existing event pipeline and emits real-time events such as patch updates, system registrations, and Salt state results. Second, a custom Node-RED integration that allows administrators to visually design automation workflows using a drag-and-drop interface. The publisher is designed to be lightweight and non-intrusive, running as a passive listener so it does not interfere with Uyuni’s current behavior. It sends structured JSON messages, supports topic-based filtering, and includes reliability features like retries, batching, and rate limiting to handle larger deployments. On top of this, the Node-RED layer provides reusable nodes for consuming events, triggering actions, and interacting with Uyuni APIs. Overall, this project makes automation in Uyuni much more accessible, reduces the need for manual scripting, and enables easy integration with external tools like Slack or Jira. It also lays a solid foundation for building more advanced automation features in the future.
Mentors: Student: Digvijay Rawat
Managing large-scale infrastructures with Uyuni involves monitoring a diverse range of Linux distributions (Debian, Ubuntu, Rocky, Alma, OpenSUSE, others) using Prometheus. While the current stack provides robust data collection via exporters (Node, Blackbox, Postgres, Apache) and visualization through Grafana, system administrators often struggle to interpret raw metrics during critical failures. This project aims to integrate an AI Monitoring Agent into the Uyuni ecosystem. The agent will process real-time metrics from Prometheus and, when an anomaly is detected, perform a deep-dive analysis. By combining metric data with live system inspection via SaltStack (leveraging mgrctl exec calls or the Salt REST API), the AI will generate enriched alerts through AlertManager. These alerts won't just say "High RAM usage"; they will explain the root cause (e.g., a specific memory leak in a process) and provide actionable mitigation steps.
Mentors: Student: AnujAgrawal
New openSUSE users face a steep learning curve navigating distribution-specific tools like zypper, YaST, Btrfs/Snapper, and systemd. This project builds a locally-running AI onboarding assistant that pairs a Small Language Model (SLM) with a Retrieval-Augmented Generation (RAG) pipeline over official openSUSE documentation. The assistant detects the user's actual system context (desktop environment, pending updates, failed services, filesystem layout) and grounds every answer in real documentation and real system signals. It runs fully offline after setup, respecting user privacy. A working proof of concept already exists with local SLM inference (TinyLlama 1.1B via llama-cpp-python), a ChromaDB-backed RAG pipeline, system context detection, CLI and Web UI interfaces, and a benchmarking framework. Deliverables: (1) production-ready SLM with tiered model support, (2) enhanced RAG pipeline with 4+ documentation sources and tuned retrieval, (3) expanded system context detection covering Btrfs/Snapper, networking, GPU, and locale, (4) jeos-firstboot module for first-boot integration, (5) systemd service with socket activation, (6) RPM packaging via OBS with subpackages for core, docs, and model, (7) security hardening and prompt injection defenses, (8) comprehensive testing across hardware tiers, and (9) blog posts and user documentation.
Mentors: Student: sharma_jp
My goal is to fix this by implementing mgrctl get a simple, kubectl-style interface for querying Uyuni resources. Think mgrctl get systems, mgrctl get errata --cve CVE-2026-1234, or mgrctl get jobs --state failed. Everything goes through the existing Uyuni REST API, so there's no new authentication logic to worry about, and the output can be a clean table, JSON, or YAML depending on what you need. By the end of the program I plan to have full coverage across five namespaces like systems, system groups, channels, scheduled jobs, and errata , with filters, structured output, and a mock-based test suite that doesn't need a live Uyuni instance to run. If time allows, I'd also like to add mgrctl describe for richer single-resource views and shell completion for bash and zsh.