Re: kdevops-ng: graduating kdevops beyond Ansible

[Daniel Gomez <da.gomez@kernel.org>]

On 18/06/2026 15.22, Chuck Lever wrote:
> 
> On Thu, Jun 18, 2026, at 5:30 AM, Daniel Gomez wrote:
> 
> + How much development effort is this? I have nearly zero time to
>   work on kdevops these days. Even with AI assistance, this seems
>   like an enormous task.

You're right that it's large, but not all of it needs to migrate. I
wouldn't move libvirt or libguestfs unless people actually want it; the
main thing that path buys you is the auto-generated UI [1].

Workflows could be migrated as-is, since Ansible is one of the languages
Windmill runs, but I think most of them are entangled with libvirt and
9p. If we're not migrating libvirt/libguestfs, porting the workflows
verbatim doesn't make sense either; the effort is better spent rewriting
them in whichever Windmill language fits (Bash, Python, Rust, ...). The
ones that are already decoupled should convert fairly straightforwardly.

One thing I should have made clearer in the cover: I lean on systemd as
the process manager, not just for QSU (QEMU in systemd), but also to run
the test suites themselves, e.g. the fstests check script as a systemd
unit. That keeps the "scripts" simple while still being powerful.

I do think the rewrite into Nix/Windmill (Bash/Python/Rust/whatever)
plus systemd is worth it. Until then, both worlds can coexist.

Link: https://www.windmill.dev/docs/script_editor/customize_ui [1]

> 
> + Also as a user of kdevops, this means I would have to spend a
>   lot of time I don't have learning the new configuration shapes
>   and figuring out how to migrate my current CI to them. That's
>   not inviting.

Agreed, the learning curve is real. The upside is that migrating also
gives you CI essentially for free: the same flows, run on Windmill's
workers and schedules, are the CI.

> 
> + What would cloud support look like in a post-Ansible world? I>   don't think Nix has impact on the cloud aspect of kdevops, and this

Correct.


>   proposal seems to shift Nix into the role of the primary kdevops
>   virtualization method. 

Correct.

> Should we simply split kdevops into an "all
>   local virtualization" project and an "all cloud virtualization"
>   project that go their separate ways? Tying cloud and local together
>   seems to be a frequent source of chafing.

Good question. The same tension arguably applies to the Nix/QSU world
versus the Debian/Fedora/openSUSE + libvirt/libguestfs world. But I
don't think kdevops is really about which tools you use underneath; it's
a broader framework and idea, the same principles applied as a
kernel-development framework whatever the technology beneath. So rather
than splitting by tooling, I'd keep the framework and let the backends
differ.

> 
> + I'd rather see a focus on addressing the technical debt of
>   continuing to support distributions that no one uses any more,
>   and moving away from requiring root to run local virtualization
>   by installing kdevops from a package. 

That's exactly why QSU was merged, and I'm very happy with the
transition. Guests now run as systemd user services with virtiofsd
instead of 9p, with all the QEMU knobs I need and KVM acceleration, and
no libvirt permissions or qemu:///session vs qemu:///system headaches.

That said, fully unwiring the controller setup and the sudo escalations
is tedious, significant work for relatively little reward. I do reach
this paths even with QSU.


> Those are narrower work
>   items that offer a bigger bang-for-buck. (You might argue that
>   Nix solves the latter problem already).

Roughly, yes: Nix solves the reproducibility part, on both the
controller and guest sides, and QSU sidesteps the libvirt permission and
SELinux/apparmor sudo configuration steps.

BTW, on the cloud side with Nix I came across terranix [2], which lets
you describe Terraform/Opentofu infrastructure in the Nix language. And
either way, once a cloud guest is up you can just install Nix on it and
run the same paths as in local virtualization, so the workflow layer is
identical regardless of which deployment users choose. Only the bringup
differs.

Link: https://terranix.org/docs/what-is-terranix/ [2]