Page MenuHomePhabricator

Store Almanac "service types" instead of "service classes"

Authored by epriestley on Feb 25 2016, 2:05 PM.
Referenced Files
F12186232: D15346.id37016.diff
Sat, Sep 16, 7:01 PM
F12186231: D15346.id37007.diff
Sat, Sep 16, 7:01 PM
F12180667: D15346.id37006.diff
Tue, Sep 12, 2:04 PM
F12180665: D15346.id37005.diff
Tue, Sep 12, 2:04 PM
Tue, Sep 12, 2:04 PM
F12180660: D15346.diff
Tue, Sep 12, 2:03 PM
F12168414: D15346.diff
Thu, Sep 7, 4:32 AM
F12159979: D15346.diff
Wed, Sep 6, 5:04 AM



Ref T10449. Currently, we store classes (like "AlmanacClusterRepositoryServiceType") in the database.

Instead, store types (like "cluster.repository").

This is a small change, but types are a little more flexible (they let us freely reanme classes), a little cleaner (fewer magic strings in the codebase), and a little better for API usage (they're more human readable).

Make this minor usability change now, before we unprototype.

Also make services searchable by type.

Also remove old Almanac API endpoints.

Test Plan
  • Ran migration, verified all data migrated properly.
  • Created, edited, rebound, and changed properties of services.
  • Searched for services by service type.
  • Reviewed available Conduit methods.

Diff Detail

rP Phabricator
Lint Not Applicable
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Store Almanac "service types" instead of "service classes".
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.

@yelirekim, if it's helpful, API impact probably doesn't affect you, but:

  • AlmanacServiceQuery->withServiceClasses(...) becomes withServiceTypes(...).
  • Pass XServiceType::SERVICETYPE instead of "XServiceType".
  • Any extension service types need a SERVICETYPE constant (you probably (?) don't have any).
  • almanac.* API endpoints have moved (you probably (?) don't use these).
  • Add some API support for Phacility use cases.
  • Additional API updates, primiarily for Phacility use cases.
chad edited edge metadata.
This revision is now accepted and ready to land.Feb 25 2016, 4:59 PM

I'm following these because I've frankensteined the existing working-copy and hosts blueprints into one megablueprint, mainly because we run one build per machine, and we run a lot of them.

I suspect this is abnormal, and is going to break in bad ways at some point.

We'll probably support that kind of thing upstream at some point, I just didn't want to add five different kinds of limits in the first iteration.

This revision was automatically updated to reflect the committed changes.