Page MenuHomePhabricator

Add isClusterDevice to Almanac query
ClosedPublic

Authored by amckinley on Apr 13 2018, 6:47 PM.
Tags
None
Referenced Files
F18854923: D19368.diff
Sat, Nov 1, 1:10 AM
F18652163: D19368.id46334.diff
Sep 21 2025, 6:56 AM
F18645385: D19368.id46330.diff
Sep 19 2025, 7:42 AM
F18597567: D19368.diff
Sep 13 2025, 3:14 AM
F18509570: D19368.id.diff
Sep 5 2025, 3:28 AM
F18502706: D19368.diff
Sep 4 2025, 10:37 PM
F18219693: D19368.id46330.diff
Aug 19 2025, 12:10 PM
F18216469: D19368.id.diff
Aug 19 2025, 7:44 AM
Subscribers

Details

Summary

Ref T13076. This will be used by the metric collection system to iterate over the cluster devices.

Test Plan

Created some cluster and non-cluster devices, searched and saw expected results.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

In the future, web, aux, etc., probably won't actually be bound to any cluster services. Maybe just pull every device, then filter them with a hard-coded check based on the name matching repo*.phacility.net or db*.phacility.net for now, and we can refine this later? I suspect this isn't actually the right check in the long term.

One reasonable version of this check in the near future might just be getAlmanacProperty('phacility.cloudwatch.enabled') or something. I think I'm going to write a beefier version of bin/provision sync pretty soon, once the new Almanac stuff deploys to admin.

src/applications/almanac/query/AlmanacDeviceSearchEngine.php
28

For consistency, prefer PhabricatorSearchThreeStateField for true/false/null fields.

I think this is fine to add anyway (with ThreeStateField) even if we don't actually use it now; the code otherwise looks right and the query capability might be useful.

This revision now requires changes to proceed.Apr 13 2018, 6:54 PM
This revision is now accepted and ready to land.Apr 13 2018, 10:48 PM
This revision was automatically updated to reflect the committed changes.