For many organizations, Kubernetes has become the preferred platform for running

software. Beyond the cloud-native crowd, software vendors, enterprise customers,

public authorities, and datacenter operators increasingly make it a hard requirement:

everything must run in Kubernetes. This includes directory services such as OpenLDAP.

On Kubernetes, the operational knowledge for running a service is codified in an

*operator* — a program that operates one particular piece of software. The core idea

is similar to that of configuration management tools like Ansible: Relative to a declared

desired state, the tool reconciles the system towards it, idempotently. An operator

applies that idea to Kubernetes: Running inside the Kubernetes cluster, it reconciles

*continuously* against a desired state expressed in *custom Kubernetes resources*,

repairing drift as it goes.

From there the conclusion is almost automatic: running OpenLDAP on Kubernetes properly

calls for an OpenLDAP operator.

For some open-source projects, Kubernetes operators exist (either provided by

the project itself, or as separate projects). For OpenLDAP, the

situation is rather problematic, though. This is why the author decided to

explore this gap. It started as an experiment, but confidence in the

feasibility and the viability of the approach increased along the way.

This talk presents `slaptain`, a Kubernetes operator for a multi-site,

multi-master replicating OpenLDAP cluster, and walks through its scope: per-pod

management of node-local `cn=config`; a whole cluster declared as a single custom

resource that expands into N-way delta-syncrepl; custom schemas, ACLs, and

databases as their own Kubernetes resources; multi-cluster replication across

independent, separately-administered clusters; and backup, restore, and

scheduled backup as first-class operations rather than a `slapcat` cron job.

One section will be dedicated to the employment of *agentic coding*: A

one-person spare-time project of this scope is only realistic because AI agents

do substantial implementation work. This approach carries the risk of producing

"AI slop" (low-quality code, hard to understand and maintain). The talk will

explain the approaches and best practices helpful for implementing reasonable,

sustainable agentic coding, creating maintainable code.

At the time of writing, slaptain is an early, experimental project, proven so far only

in a homelab. The general approach, though, is proven. The talk will close with the

question: What is it that we have here? A toy? An academic proof of concept? Or

something with a future?

Reference: https://github.com/chuck-chuck-chuck-net/slaptain