Changes to Almanac
Almanac Devices now support a "status" property, which currently has two values: "Active" and "Disabled".
If you do not interact with Almanac over the API, this change likely has minimal impact: the net effect is roughly that you can now "Disable" devices in Almanac and it will do what you'd expect.
Broadly, Almanac now has a formal concept of "active bindings" for services. Only "active" bindings will be used by Phabricator. Bindings are not "active" if:
- the binding itself has been disabled; or
- the bound device has been disabled.
The almanac.service.search API method now supports an "activeBindings" attachment, which works exactly like the "bindings" attachment, except that it returns only active bindings.
Almanac can query "active" bindings efficiently if you only request active bindings. If a caller is only interested in active bindings, using the "activeBindings" attachment is simpler and more efficient than using the "bindings" attachment and filtering bindings on the client.
Drydock now uses only "active" bindings when allocating hosts.
Diffusion now uses only "active" bindings for repository operations.
If you have callers which interact with Almanac, it's likely advisable to update them to use the "activeBindings" attachment and respect the "status" or "disabled" fields from almanac.device.search and other similar methods, if applicable.
If you decommission hosts, you can currently disable bindings in Almanac but can't actually mark the device as disabled.
- (D21627) Almanac devices should support a "Disabled"/"Archived"/"Decommissioned" status.
- (D21627) This should have read/write API access.
- (D21628) Repositories and Drydock should not select bindings to disabled devices during operation.
- (D21635) When a device is disabled, we shouldn't accept associated SSH keys from it any longer.
- (Yes) Double check: does disabling a device cascade a cache dirty to the repository URI map?
Punting these reasonable ideas:
- The service view should show a summary of devices with active bindings.
- The service view should probably hide disabled bindings and bindings to inactive devices by default, with hints "Show X more disabled bindings / bindings to disabled devices".
These are nice to have, but I think no one's turnover rate for devices and bindings is going to actually require them for at least a couple years. Specifically, the problem they solve is if you swap repo hosts every few days the "Bindings" table when viewing a Service could end up with a very large number of entries, but I can't imagine that even ambitious installs are swapping more than, say, 20 hosts a year.