Players, plays, and their pods

You describe your equipment once, and then start and stop media by creating and deleting objects. Each resource changes at its own pace:

• You write a Player once for each unit of equipment. It selects the unit’s screen, speakers, and GPU from the devices that the other operators publish, with the same CEL selectors that a hand-written ResourceClaim uses.
• You write a Remote once for each controller, and a Keymap once for each controller model that needs one.
• You write a Play for each run of media. Create it to start, and delete it to stop. The operator deletes a finished Play after its ttlSecondsAfterFinished.

The operator turns each Play into one playback pod on the machine with the hardware. It claims the speakers and the other devices only while that Play runs. An idle Player keeps only its display claim, so other workloads can use the rest of its devices between runs.

What runs

The install puts three Deployments in liken-system: the operator, the media API, and the message bus, which is one Mosquitto broker. It also puts one DaemonSet there: the capabilities agent, with one pod on each node with a GPU, which publishes what each GPU’s media driver can do.

The operator then creates two more kinds of long-running pod: an idle pod for each Player, which draws the screen while nothing plays, and a pod for each Remote, which reads the controller and sends its button presses to the message bus.