fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

CB-626: rename the config key fleet: -> roles:, with a read-both shim #130

New Issue
Open
opened 2026-08-22 21:35:43 +02:00 by ltms · 0 comments
ltms commented 2026-08-22 21:35:43 +02:00
Owner
Copy Link
Copy Source

Part of CB-621 (#125). Do this after the move, not during it.

Why

Inside a product called fleet, a config section called fleet: is redundant, the same way a bridged: section inside bridged.yaml would be. The section holds role pools, so roles: says what it is.

fleet:            ->   roles:
  leaders:                leaders:
  architects:             architects:
  developers:             developers:
  reviewers:              reviewers:
  charters:               charters:

The danger

fleet.leaders.*.tab is the lead-identity pin. The daemon finds the lead by its tab label. Get this key wrong and the lead is resolved as a worker, which refuses every orchestration call. That failure is loud but total.

There is a second danger that is quiet. bridged.yaml is gitignored, so no worker can see it. A change to what a config key means therefore ships green through CI and breaks the live fleet at restart. This project has hit that before.

Scope

  • Read roles: first, fall back to fleet:.
  • When the old key is used, log one WARN at startup naming both the old and the new key.
  • Update bridged.example.yaml and every doc.
  • Update the live gitignored bridged.yaml by hand at merge time, because no worker and no CI run can do it.
  • Remove the fallback at 3.0.

Acceptance criteria

  • A config using only fleet: starts and logs exactly one WARN.
  • A config using only roles: starts with no WARN.
  • A config using both fails to start with a clear message. Do not silently pick one.
  • After a restart on the new key, fleet_whoami returns primary. This is the check that proves the tab pin still resolves; run it live.
  • BridgedConfigTest covers the nested key in both directions. Note that the existing example-vs-code check matches only column-0 keys, so a nested key is invisible to it. Extend the check or this rename is untested.
Part of CB-621 (#125). Do this after the move, not during it. ## Why Inside a product called fleet, a config section called `fleet:` is redundant, the same way a `bridged:` section inside `bridged.yaml` would be. The section holds role pools, so `roles:` says what it is. ```yaml fleet: -> roles: leaders: leaders: architects: architects: developers: developers: reviewers: reviewers: charters: charters: ``` ## The danger `fleet.leaders.*.tab` is **the lead-identity pin**. The daemon finds the lead by its tab label. Get this key wrong and the lead is resolved as a worker, which refuses every orchestration call. That failure is loud but total. There is a second danger that is quiet. `bridged.yaml` is gitignored, so **no worker can see it**. A change to what a config key means therefore ships green through CI and breaks the live fleet at restart. This project has hit that before. ## Scope - Read `roles:` first, fall back to `fleet:`. - When the old key is used, log one WARN at startup naming both the old and the new key. - Update `bridged.example.yaml` and every doc. - Update the live gitignored `bridged.yaml` **by hand at merge time**, because no worker and no CI run can do it. - Remove the fallback at 3.0. ## Acceptance criteria - A config using only `fleet:` starts and logs exactly one WARN. - A config using only `roles:` starts with no WARN. - A config using both fails to start with a clear message. Do not silently pick one. - After a restart on the new key, `fleet_whoami` returns `primary`. This is the check that proves the tab pin still resolves; run it live. - `BridgedConfigTest` covers the nested key in both directions. Note that the existing example-vs-code check matches **only column-0 keys**, so a nested key is invisible to it. Extend the check or this rename is untested.
ltms added this to the 2.0 — one operation centre, many hosts milestone 2026-08-22 21:35:43 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone 2.0 — one operation centre, many hosts
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#130
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?