[usage] Lookup stripe customers for each team in a usage report

[andrew-farries]

Description

Add a stripe package to the usage reconciler and use it to find all Stripe Customers who have registered usage in the preceding month.

By querying the Stripe API for all teamIds occurring in the usage report, we are able to find a list of Stripe Customers who should have their subscriptions updated to register usage.

This PR just finds and logs the Customers occurring in the usage report. In a subsequent PR these Customers will be updated to register their usage.

Related Issue(s)

Part of #9036

How to test

• Get a kube context for the staging cluster (gcloud auth login then gcloud container clusters get-credentials ...) - the exact commands can be taken from the GCP console.

• Port forward to the staging database:

kubectl port-forward svc/cloudsqlproxy 3306:3306

• Get some Stripe test mode API keys from the Stripe dashboard and save them in components/usage/apikeys. The file should look like:

{
  "publishableKey": "foo",
  "secretKey": "bar"
}

• Run the usage reconciler against the staging database:

DB_HOST=localhost DB_USERNAME=gitpod DB_PASSWORD=<> DB_PORT=3306 go run . run --api-key-file ./apikeys

(the env vars, including password, can be found in the server pod by running):

kubectl exec server-849f6f8895-8kct9 -- env | grep DB_

After 1 minute the reconciler will run and display output like:

{"level":"info","message":"about to make query \"metadata['teamId']:'0163ce3d-d46d-4c71-9d23-80d5e014959b' OR metadata['teamId']:'2db3d0ae-9fa2-41ed-9781-acfc7e17294b' OR metadata['teamId']:'0d39eefc-d1b7-461d-a4e5-03826b3dd054' OR metadata['teamId']:'0a6486da-b080-4f66-ba86-98f5a03374b5' OR metadata['teamId']:'14f79ba1-6e24-46de-aa80-12f63e58ea5f' OR metadata['teamId']:'7981ba4e-68fe-4d0a-afa1-e21b428bd7d0' OR metadata['teamId']:'af870004-62e5-4b44-9395-cd37abb10e2e' OR metadata['teamId']:'58ba9114-49ee-4538-8550-6f2bace66ac4'\"","serviceContext":{"service":"usage","version":""},"severity":"INFO","time":"2022-06-15T06:36:28Z"}
{"level":"info","message":"found customer \"Test Customer (for invoice generation)\" for teamId \"2db3d0ae-9fa2-41ed-9781-acfc7e17294b\"","serviceContext":{"service":"usage","version":""},"severity":"INFO","time":"2022-06-15T06:36:28Z"}

Showing the query that was run against the Stripe API and the 1 customer that was found with a matching teamId.

Release Notes

NONE

• /werft with-payment

[werft-gitpod-dev-com]

started the job as gitpod-build-af-generate-test-invoice.9 because the annotations in the pull request description changed
(with .werft/ from main)

[werft-gitpod-dev-com]

started the job as gitpod-build-af-generate-test-invoice.10 because the annotations in the pull request description changed
(with .werft/ from main)

[jankeromnes]

Many thanks! Will take a look. 👀

[jankeromnes]

Interesting -- is placing an untracked, secret file next to the cmd the recommended way to provide credentials to a Go component? 👀 (I haven't worked on Go component secrets before.)

[andrew-farries]

I think this way works well here. When the component runs in a pod it takes the credentials file in the same way (file on disk, location passed via --api-keys-file).

How would you expect the necessary api keys to be provided when running the usage component locally?

[jankeromnes]

Thanks for the insight!

How would you expect the necessary api keys to be provided when running the usage component locally?

Hmm, I never run components locally -- only inside a complete Gitpod deployment (with secrets configured for Werft or staging/production)

[andrew-farries]

Makes sense. I think @easyCZ is keen to move away from requiring preview environments to develop components. When working on the usage component I think the intention is to run it locally, port forwarding to a database as necesary.

[jankeromnes]

Interesting. I guess you found this limit by testing. Is the value 10 documented somewhere? 👀

[andrew-farries]

Not documented anywhere I could find. It appeared in an error message when trying larger queries.

[jankeromnes]

Thanks! No worries -- I asked for more references, because I also wonder whether the actual limit can be different between "test" and "live" mode. But 10 should work.

(I guess this will just potentially fire a lot of Stripe queries in production, because we have many teams there -- but let's see about that when it really happens.)

[andrew-farries]

Yes, I wondered about differences between live vs staging too.

We will likely need to rate limit our Stripe API calls in production in general. For this search endpoint the rate limit is:

Rate limits
We apply a rate limit of up to 20 read operations per second which applies for all search endpoints in both live mode and test mode. Live mode and test mode limits are separate.

[jankeromnes]

Works like a charm, thanks! 🎉

Tested by setting up usage-based billing for a team, running a few workspaces, and checking the usage component logs (it found the customer).