Loading
Track a machine's heartbeat from creation, not from the next Acquire
What does this MR do?
The docker+machine provider registers a machine with the heartbeater as soon as docker-machine create succeeds, instead of waiting for the next Acquire to notice it.
Why was this MR needed?
The ticker only refreshes machines it already knows about, and a machine only became known through Acquire. If Acquire stops right after a machine is created, that machine never gets a runner_manager_heartbeat label while the rest of the fleet keeps refreshing. To external cleanup it looks like an orphan.
This happened on gitlab.com today. A worker created a machine at 10:05:12 and was disabled by the health check at 10:05:10 (#39726 (closed)), so no Acquire ran for an hour and the machine stayed unlabelled.
Registering a machine is one map write that records its first due time, the same as the first sighting in updateMachines did. The label write still comes from the ticker or the next Acquire, at the machine's random offset within the interval and under the shared semaphore, so a manager booting its idle pool does not burst label writes on top of the creations.
The call needs no condition of its own. beat returns immediately when HeartbeatInterval is unset or the driver does not support labels, which is what protects the updateMachines call today.
What's the best way to test this MR?
TestMachineCreationRegistersHeartbeat fails on main.
What are the relevant issue numbers?
Edited by Igor