Aggregator entity: bootstrap global aggregators into divviup-api deployment

[tgeoghegan]

We want Janus instances operated by Divvi Up to be just like any other aggregator, in that they are rows in the database table for aggregators, except that they will be global aggregators, available for use in tasks for any account. Pairing a per-account aggregator is a subscriber's responsibility, but we want to ensure that Divvi Up's Janus is available in divviup-api deployments. Our deploy tools will need a means of registering one or more global aggregators when deploying divviup-api.

[tgeoghegan]

This work might end up being in janus-ops, but depending on the solution strategy it could also involve code changes here in divviup-api: maybe we could provide the specifications of global aggregators in configuration and divviup-api would write them into its database at startup if they're not already there?

[jbr]

How strong is the need to automate this? The simplest thing that could reasonably work is for a human to configure this database state once for each deploy environment, which seems comparable to configuring an admin Account (which similarly is not bootstrapped).

[jbr]

If it is important to automate, I'd lean towards either exposing a protected http api, a binary target, or env variables with insert-on-boot behavior over having another process insert into the database, which should be considered private state of the divviup-api process

[tgeoghegan]

I think you're right, this is something that would happen infrequently enough that we could live with having an admin interface to divviup-api -- which could be accessed either through a command line tool or a web UI -- that allows registering global aggregators. We'd need to write a runbook for registering a global aggregator.

Another option would be to make this part of the janus deploy process: after it deploys the aggregator, the janus deploy process could hit the admin-only POST /aggregators endpoint on divviup-api to register the newly deployed aggregator. If we pursue that, then there's probably no work here in divviup-api and all the action would be in janus-ops.

[jbr]

And that could piggyback on the account tokens in #195, in that we could create a token on the admin account. Any such tokens would have to be closely guarded, though, since they are omnipotent. Bootstrapping an admin token from divviup-api to Janus or janus-ops would need to be a clipboard-based configuration, which we've avoided elsewhere, though

[jbr]

Closing tentatively because I believe this has been resolved by manually configuring staging (and in the future, by the existence of #269