Dustin 4bb72900fa Begin lock/unlock implementation ... This commit introduces two HTTP path operations: * POST /api/v1/lock: Acquire a reboot lock * POST /api/v1/unlock: Release a reboot lock Both operations take a _multipart/form-data_ or _application/x-www-form-urlencoded_ body with a required `hostname` field. This field indicates the name of the host acquiring/releasing the lock. the `lock` operation also takes an optional `wait` field. If this value is provided with a `false` value, and the reboot lock cannot be acquired immediately, the request will fail with an HTTP 419 conflict. If a `true` value is provided, or the field is omitted, the request will block until the lock can be acquired. Locking is implemented with a Kubernetes Lease resource using Server-Side Apply. By setting the field manager of the `holderIdentity` field to match its value, we can ensure that there are no race conditions in acquiring the lock; Kubernetes will reject the update if both the new value and the field manager do not match. This is significantly safer than a more naïve check-then-set approach.		2025-09-24 08:25:32 -05:00
..
basic.rs	catcher: Add trailing newline to body text	2025-09-24 08:17:06 -05:00
lock.rs	Begin lock/unlock implementation	2025-09-24 08:25:32 -05:00
main.rs	Begin lock/unlock implementation	2025-09-24 08:25:32 -05:00