Operational commands, from request to result.

01 / Context

The problem

Link needed a way to run Django management commands in the background from its web interface. A launch button was only the start: two simultaneous requests must not run the same work twice, output needs to survive the process, and a database record must not stay unfinished after its Kubernetes Job has stopped.

02 / Responsibility

My contribution

I built the workflow across the database model, execution logic, Kubernetes integration and web UI. Operators can launch an allowed command, follow its progress and read its output in one place.

03 / Approach

Key decisions

I used a persistent job lifecycle and ordered row locks to serialize competing claims. Commands explicitly opt in to the UI, with separate permissions to launch jobs and inspect them. Each Kubernetes Job inherits the configured environment from an existing CronJob template and has automatic retries disabled, so a failed command is not silently repeated. Buffered output is appended in the database, and a reconciliation process checks unfinished records against Kubernetes state.

1. 01

   Authorize

   Check user permissions and restrict the launch form to explicitly allowed commands.

2. 02

   Claim and execute

   Persist the request, serialize competing claims and launch a Kubernetes Job.

3. 03

   Report and reconcile

   Capture output and terminal state; reconcile unfinished records with Kubernetes.

04 / Result

The result

Delivered the workflow in four stages: models, domain logic, infrastructure and UI. The merged implementation gives permissioned users a route from command selection to status and captured output, with a verification command that exercises the full path.