DEV Community: Bharath Nelapatla

Reviving My Linux Mastery Game from a Merge Conflict — A Finish-Up-A-Thon Comeback

Bharath Nelapatla — Mon, 25 May 2026 11:20:33 +0000

*This is a submission for the GitHub Finish-Up-A-Thon Challenge*

What I Built

Enterprise Linux Mastery Game — a local-first, AI-mentored terminal game for practicing real enterprise Linux administration. The mentor sets a scenario (a paging-hour incident, a permissions puzzle, a 5xx spike). You type Linux commands. They run inside a hardened Docker sandbox. An AI judge grades you on correctness, safety, and efficiency and gives coaching feedback.

I started it as a January side-project that I genuinely cared about — I work in enterprise IT training and I've watched too many engineers learn Linux the wrong way, by memorising commands instead of investigating systems. The game was meant to fix that for myself and the trainees I work with.

Then I hit a wall. The repo sat for four months with a visible merge conflict in the README and a backend wired to a paid LLM API I'd lost access to. The Finish-Up-A-Thon was the push I needed to actually finish it.

Repository: https://github.com/Bharathtrainer/Linux-game
Architecture: FastAPI + Ollama (Llama 3.1) + Docker sandbox + YAML scenarios + a CLI client. Everything runs locally. No cloud API key.

Demo

A real play session captured tonight. Player picks the entry level, investigates a "/var disk filling up" scenario inside the sandbox, and gets a graded verdict from the AI judge.

The judge scored this run 84/100 — three correct investigation commands, perfect safety, near-perfect efficiency. The coaching identifies one specific improvement: running du on the directory directly instead of its contents.

================================================================
================ ENTERPRISE LINUX MASTERY GAME =================
Local-first. AI-mentored. Sandboxed.
Levels:

entry
operator
engineer
sre
Pick a level number: 1
Starting mission for player1 @ level=entry...
Production server: disk filling fast
An alert just paged you. The /var partition on a production app server
is at 96% and climbing. The on-call engineer needs to know what's
eating the space before the disk fills and the application crashes.
You have shell access. No need to delete anything yet — first, find
the offender.
Objective: Identify which directory or file is consuming the most
space under /var.
Commands: type a shell command, or one of:
/hint    — ask the mentor for a Socratic hint
/done    — submit your attempts for grading
/quit    — give up and exit
[entry] $ ls -la /tmp/sandbox/var
total 20
drwxr-xr-x 5 sandbox sandbox 4096 May 25 08:31 .
drwxr-xr-x 3 sandbox sandbox 4096 May 25 08:31 ..
drwxr-xr-x 2 sandbox sandbox 4096 May 25 08:31 cache
drwxr-xr-x 2 sandbox sandbox 4096 May 25 08:31 lib
drwxr-xr-x 2 sandbox sandbox 4096 May 25 08:31 log
[exit 0]
[entry] $ du -sh /tmp/sandbox/var/*
8.0K    /tmp/sandbox/var/cache
8.0K    /tmp/sandbox/var/lib
81M     /tmp/sandbox/var/log
[exit 0]
[entry] $ du -h /tmp/sandbox/var/log/app.log
80M     /tmp/sandbox/var/log/app.log
[exit 0]
[entry] $ /done
Grading...

================================================================
============================ RESULT ============================
Verdict:     Good start, but you haven't yet identified the
largest file.
Solved:      False
Score:       84/100
Correctness: 8/10
Safety:      10/10
Efficiency:  9/10
Coaching:
Your first command was a good investigation step. The second
command effectively used du to find large directories under
/var/log. However, it would be more efficient to use du on
the log directory directly instead of its contents. Remember
that -h is not needed for this specific scenario.

Missed concepts: du, directory vs file

The judge is appropriately strict — the player identified the large file but didn't actually confirm the answer with a more decisive command. That kind of nuanced grading is what makes this useful for training rather than just gamification.

Try it yourself:

git clone https://github.com/Bharathtrainer/Linux-game
cd Linux-game
docker build -t linux-mastery-sandbox sandbox/
ollama pull llama3.1
cd backend && pip install -r requirements.txt && uvicorn main:app --reload

# In a second terminal:
python play.py

The Comeback Story

Where the project was before this week:

README.md had unresolved git merge conflict markers visible right on the GitHub landing page (<<<<<<< HEAD, >>>>>>> and everything in between). Anyone clicking the repo saw raw conflict markup as the first thing.
The backend was hard-wired to NVIDIA NIM, a paid LLM service I'd lost access to. Without those env vars every endpoint 500'd.
The core/sandbox.py file — the literal heart of the game, the thing that runs user commands safely — did not exist. The judge endpoint was scoring imaginary commands.
api/mission.py was a single stub that returned "Mission started" and did nothing.
Two empty files named git and main sat at the repo root, debris from a fat-fingered shell redirect months ago.
Only one scenario YAML existed, with four fields. No challenge text, no setup script, no success criteria.
The mentor and judge prompts were three lines each. No JSON schema. No grading rubric.

It looked 30% done. It was actually closer to 10%, because the missing pieces were the load-bearing ones.

What I changed, in commits that read like a story:

Resolve the merge conflict and clean up debris. Fixed the README, deleted the empty artifact files, added a THE_COMEBACK.md for the full revival log.
Swap NVIDIA NIM for local Ollama. Renamed core/nim_client.py → core/llm_client.py. Default provider is Ollama (free, local, no key). Kept NIM as a fallback via LLM_PROVIDER=nim. Mapped legacy NIM model names to Llama 3.1 so older callers don't break.
Add the missing sandbox runner. Wrote core/sandbox.py — a one-shot Docker runner with --network=none, memory and CPU limits, a per-command timeout, and a non-root user (UID 1000). The security boundary of the entire game.
Build the real game loop and ground the prompts. Rewrote api/mission.py as a proper orchestrator (/start, /run, /finish). Pinned a three-axis grading rubric in the judge prompt. Added three new scenario YAMLs (operator_runaway_process, engineer_permissions, sre_log_triage) with real challenge narratives — the part of this project no AI could write for me, because it requires actually knowing which enterprise Linux problems happen in the wild.
CLI client and polished README. Wrote play.py to make the game playable. Added an architecture diagram, quickstart, screenshots, and a transcript of a real play session.

You can see the whole arc in the commit history. Importantly, the unresolved merge conflict is still visible in the historical README at commit aed0242 — anyone who wants to verify the "before" state was real can see it for themselves.

What I learned: Side projects die in the gap between almost demoable and actually playable. The commits above are mostly boring glue — subprocess wrappers, Pydantic models, JSON parsers, a CLI loop. None of it was hard. All of it was the kind of work I'd previously dropped because "the interesting part is done." The Finish-Up-A-Thon framing helped me see the gap for what it really was: not missing capability, just missing patience for the unglamorous middle.

My Experience with GitHub Copilot

Three places Copilot did real, specific work — not generic autocomplete:

1. Resolving the merge conflict. I opened the broken README in VS Code and asked Copilot Chat:

"Resolve this Git merge conflict in this README. Keep the richer 'Enterprise Linux Mastery Game' content but make it the start of a real README — add sections for what it does, quickstart, and configuration."

It produced a clean draft I then edited for the Ollama specifics. Faster than reading both sides and hand-merging.

2. Mapping the legacy NIM model names to Ollama tags. I gave Copilot the original model_router.py and asked:

"These three NIM-specific model identifiers need to map to Ollama tags. Generate a fallback mapping that defaults to llama3.1 when an exact match isn't available, and keep the level→model selection logic intact."

The _resolve_model_alias method in llm_client.py came out of that interaction.

3. Drafting the sandbox runner. This was the most useful one. I described what I wanted:

"Write a Python function that runs a shell command inside a one-shot Docker container using the docker CLI via subprocess. Hard timeout, no network, memory and CPU limits, runs as UID 1000. Return a dataclass with stdout, stderr, exit_code, and a timed_out flag."

Copilot drafted the structure including the subprocess.TimeoutExpired handling I would have forgotten. I added the sandbox_image_exists() health check and the FileNotFoundError branch for "Docker not installed."

Where Copilot specifically didn't help — and I want to be honest about this:

It didn't write the scenario YAMLs. Those needed domain knowledge about which enterprise Linux problems are pedagogically valuable. Generic AI-written scenarios would have read like textbook exercises. The disk-full, runaway-process, permissions-puzzle, and log-triage scenarios are based on real incidents I've coached trainees through.
It didn't write the judge rubric. The three-axis scoring (correctness 60% / safety 25% / efficiency 15%) reflects how I actually evaluate engineers, not how an LLM thinks grading should work.
It didn't make the architectural call to keep NIMClient as a backward-compatible alias rather than ripping it out. That was a judgement call to keep the commit diff small and reviewable.

The honest version of "how Copilot helped" is: it removed the friction of writing boilerplate — subprocess glue, Pydantic models, JSON parsing helpers — so I could spend my limited attention on the parts only I could do. For a side project being revived under time pressure, that ratio of "boring code automated, judgement work preserved" is exactly the right one.

THE_COMEBACK.md

OpenShift Virtualization Migration Advisor — Local-First, Powered by Gemma 4 26B MoE

Bharath Nelapatla — Mon, 25 May 2026 07:07:29 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

OpenShift Virtualization Migration Advisor — a local-first assessment tool that ingests legacy hypervisor configurations (VMware .vmx, libvirt domain XML, OVF, RHV/oVirt exports) and produces a structured migration report for moving workloads to Red Hat OpenShift Virtualization.

The problem it solves is specific and unglamorous: enterprises consolidating off vSphere and legacy KVM have a discovery bottleneck. Their VM inventories live in config files that contain infrastructure secrets — storage paths, VLAN topology, encryption key references, FIPS posture, licence keys. Sending those to a hosted LLM is a non-starter for regulated workloads.

So I built the assessment to run entirely on the host machine. Paste a config or upload an inventory → get a six-section migration report covering inventory mapping, OpenShift Virt primitive equivalents (VirtualMachine, DataVolume, NetworkAttachmentDefinition, StorageClass), compatibility risk flags, MTV-vs-virt-v2v tooling recommendation, effort sizing, and security posture preservation. Nothing leaves the box.

Demo

The tool generated this report from a single VMware .vmx file, fully on-device using Gemma 4 26B MoE via Ollama. Screenshots below; full generated output included so judges can see the actual model output, not a curated highlight.

Local Gradio UI. Pick a sample → click Generate → report streams in from local Gemma 4.

Six-section migration report streamed from Gemma 4 26B MoE running locally. No cloud API calls.

Full Report (generated locally)

From samples/vmware-web-tier.vmx — 311.7s on a 16 GB-VRAM laptop with 85% CPU offload

> Source detected: VMware vSphere (.vmx)
> Model: gemma4:26b
> Generated locally in: 311.7s on a consumer laptop GPU + CPU offload

1. Inventory Summary

Name	vCPU	Memory	Disk(s)	Network(s)	Guest OS	Notes
web-tier-01	4 (2 sockets × 2 cores)	8192 MiB	web-tier-01.vmdk	VLAN-100-DMZ	rhel9-64	Production Nginx/PHP-FPM; requires UEFI Secure Boot; vSphere encrypted.

2. OpenShift Virtualization Equivalents

Resource	OpenShift Virtualization Primitive	Configuration Details
Compute	`VirtualMachine`	`spec.template.spec.domain.cpu`: 2 sockets, 2 cores; `spec.template.spec.domain.resources.requests.memory: 8Gi`
Firmware	`VirtualMachine`	`spec.template.spec.domain.firmware: efi` (Secure Boot enabled)
Storage	`DataVolume`	`storageClassName: [not specified in source]`; requires conversion from `pvscsi` to `virtio-scsi`
Network	`NetworkAttachmentDefinition`	Target VLAN-100-DMZ via Multus CNI

3. Compatibility & Risk Flags

Critical — SCSI Controller Mismatch: Source uses pvscsi. OpenShift Virt requires virtio-scsi. Driver injection or kernel reconfiguration may be necessary if the RHEL 9 initramfs lacks virtio drivers (unlikely for RHEL 9).
Critical — Encryption / KMS Breakage: Source uses vSphere-specific KMS (vsphere-kms-key-001). This encryption cannot be migrated. Data must be decrypted during migration or re-encrypted using OpenShift-native methods (encrypted PVCs).
High — Network Driver Mismatch: vmxnet3 must be replaced with virtio for optimal performance and compatibility.
High — UEFI Secure Boot: OpenShift Virt supports UEFI; the migration pipeline must ensure the VirtualMachine object is correctly configured with firmware: efi and a bootloader compatible with the new virtual hardware.
Medium — CD-ROM dependency: The rhel-9.4.iso is attached. Must be manually re-attached via a ConfigMap or DataVolume if required for post-migration configuration.

4. Migration Path

web-tier-01: MTV (Migration Toolkit for Virtualization).
Justification: MTV is the recommended path for vSphere-to-OpenShift migrations — it automates the conversion of VMDK to DataVolume and handles the mapping of vSphere networks to NetworkAttachmentDefinition.

5. Effort & TCO Notes

Effort (web-tier-01): S Justification: Single, modern Linux guest (RHEL 9) with standard hardware requirements and no complex PCI passthrough.
TCO / Licensing:
- Requires OpenShift Container Platform (OCP) subscription
- RHEL guest licensing applies (standard RHEL / RHEL for Virtual Datacenters)
Consolidation: If other web-tier nodes exist in the source, migrate them in a single MTV plan to reduce migration window and operational overhead.

6. Security & Compliance

Source Security Feature	OpenShift Virtualization Equivalent
vSphere Encryption (KMS)	Encrypted PVCs (via StorageClass / CSI) or `dm-crypt` within the Guest OS
VLAN-100-DMZ Isolation	`NetworkAttachmentDefinition` + `NetworkPolicy` for micro-segmentation
UEFI Secure Boot	`VirtualMachine` spec `firmware: efi` with Secure Boot enabled
Production Workload Isolation	Namespace-level isolation in OpenShift

Code

Repository: https://github.com/Bharathtrainer/openshift-migration-advisor

How I Used Gemma 4

I chose Gemma 4 26B MoE (gemma4:26b) after starting on 31B Dense and discovering it was the wrong tool for this workload.

The honest path: I picked 31B Dense first because the highest-quality reasoning seemed like the obvious choice for infrastructure assessment. Two problems surfaced on real-world inputs:

Ollama Flash Attention prefill stall on Dense (ollama#15350) hangs the 31B variant on prompts beyond ~3–4K tokens. A multi-VM datacenter inventory blows past that on the first VM. The bug is specific to Dense's hybrid sliding+global attention; MoE handles the same prompts cleanly.
Active-parameter efficiency. 26B MoE activates ~4B parameters per token versus 31B for Dense. On a consumer laptop GPU, that's the difference between a model that works (with some CPU offload) and one that doesn't fit at all.

What I kept from picking MoE over Dense:

256K context window — enough to ingest an entire small-datacenter inventory in one shot
Stable long-prompt prefill on Ollama's current build
Native reasoning mode via the <|think|> system-prompt token
Workable throughput on consumer hardware — generation runs even when 85% of layers spill to CPU

Honest performance note: the report above generated in 311.7 seconds on a 16 GB-VRAM laptop GPU with 85% CPU offload (ollama ps confirms the split). On a workstation with 24+ GB VRAM the same generation should land in 30–60 seconds. This is exactly the kind of detail you want a tool to expose, not hide — local AI's pitch is data sovereignty, and the tradeoff is hardware-dependent latency. Field engineers running this for offline assessment will accept 5 minutes for a report they can't legally send to a cloud API.

When MoE is not the right pick: short, single-turn, hard math/code reasoning where Dense's per-token capacity matters more than throughput. For long, structured, enterprise-document reasoning over large configs, MoE wins. That's the call this build makes, and the rationale is documented in the README with the GitHub issue link, not vibes.

One Gemma 4-specific detail worth flagging: I follow the recommended sampling (temperature=1.0, top_p=0.95, top_k=64) and set OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q4_0 to keep the KV cache compact enough for a 16K context window. Those four config values are the difference between this running at usable speed and not running at all.

Built entirely on a laptop. No cloud API key was used at any point in the construction of this submission. The report you see above was generated by Gemma 4 running on the same machine.