**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.
---
//Implementation Details//
See T13630. See PHI1331.
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.
- The service view- (D21628) Repositories and Drydock should show a summary ofnot select bindings to disabled devices with active bindings.during operation.
Also:
- The service view should probably hide disabled bindings and bindings to inactive devices by default- (D21635) When a device is disabled, with hints "Show X more disabled bindings / bindings to disabled devices"we shouldn't accept associated SSH keys from it any longer.
- Repositories and Drydock should not select bindings to disabled devices during operation.- (Yes) Double check: does disabling a device cascade a cache dirty to the repository URI map?
Also:Punting these reasonable ideas:
- When a de- The service is disabled, weview shouldn't accept associated SSH keys from it any longer show a summary of devices with active bindings.
- Double check: does disabling a device cascade a cache dirty to the repository URI map?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.