Page MenuHomePhabricator

Move Phacility provisioning to Piledriver
Open, NormalPublic

Description

See T13542.


Stuff Piledriver could use:

  • Almanac search by property and/or property value, i.e. "find any device with property X" or "find any device with property X set to value Y". This doesn't have to be high-performance or well-indexed.
  • See PHI1331. It would be nice to have better support for a "destroyed" lifecycle stage in Almanac.

Vaguely nice to have:

  • See related T13220. API-level support for a "viewer()" policy. The default policy for Almanac devices is "Administrators", and a bot user may not satisfy this. Templates could configure an explicit policy, but "viewer()" would be a reasonable default. Piledriver can figure out the acting user PHID with user.whoami and effect this policy, but this could be cleaner with "viewer()".

Revisions and Commits

Restricted Differential Revision

Event Timeline

epriestley triaged this task as Normal priority.Mar 6 2021, 8:03 PM
epriestley created this task.

Can Piledriver be implemented as an Arcanist toolset?

Probably. As with Phage, there's a fairly bright line between the Phacility-specific parts and the generic parts. Separating it probably doesn't make sense right away since the two parts are mutating in tandem, but I think it can move to Arcanist once it works.

One potential issue here is that Piledriver may benefit from access to Phabricator components, like the Query classtree. This might motivate moving this tree to Arcanist.

Where is pile metadata stored?

Currently, Piledriver bootstraps resource discovery without any storage. On the one hand this is nice to have, since it means there can never be a DRY issue where the metadata says resources are in one state and the resource API says they're in a different state.

However, it limits our ability to do things like "track which template was used to build a pile" or "log changes to a pile", which are almost certainly necessary in the long run. This can probably just go into Almanac? It doesn't feel like a separate application.

There's a bootstrapping issue here, where Piledriver needs to create admin entries in Almanac but also, conceivably, needs to create admin in the first place. The admin records could exist on secure, or the CLI could maintain a soft dependency on Almanac and bootstrap itself in multiple stages. This is probably not much of an issue in practice since (at least today) you can manually drive a pile using the AWS console without significant difficulty until Piledriver can finish driving it.

epriestley added a revision: Restricted Differential Revision.Mon, Mar 29, 4:44 PM
epriestley added a commit: Restricted Diffusion Commit.Mon, Mar 29, 4:45 PM