[Usage-based] Attribute workspace instances to a Team on start

[jankeromnes]

Description

When a workspace instance starts, we want to determine and persist which "cost center" that instance's usage should be attributed to:

• If wsi.attributedTeamId is set to a specific Team ID, then that Team "owns" the instance's usage
  • This means that the instance's usage time will be reflected in the Team's Usage dashboard, and in their Stripe invoices if usage-based billing is enabled
• If wsi.attributedTeamId is not set, then it's the workspace owner (User) who owns the instance's usage
  • This means that we default to user billing or their free credits when no Team is attributed

Reminder: We need to do this on instance start, because the usual attribution links can change over time.

Related Issue(s)

Fixes #10533

How to test

1. Should build
2. In the DB, d_b_workspace_instance should have a attributedTeamId column that defaults to empty string ('')
3. If you start a workspace without any Project:
   • its attributedTeamId should be empty (i.e. usage is attributed to you)
4. If you create a Project under your User, and start a workspace for that User Project:
   • the attributedTeamId should also be empty (i.e. usage still attributed to you)
5. If you create a Project under a Team, and then start a Workspace for that Team Project:
   • the attributedTeamId should now be set to the Team's ID (i.e. usage is attributed to the team)

Release Notes

NONE

Documentation

[jankeromnes]

Placing this method in UserService is debatable. For example, this logic could be in-lined in workspace-starter.ts (which already has projectDb injected).

My reason for placing it here was to allow an extension point where ee/UserService could detect if payment is enabled, and use a different logic (i.e. attribute all usage to a "cost center" team, instead of the project's team).

I don't have any opinion on this -- feedback most appreciated.

[andrew-farries]

Not strongly opinionated here either but your reasoning here makes sense; the subject of cost center vs team has already come up in discussions.

[werft-gitpod-dev-com]

started the job as gitpod-build-jx-attributed-team.3 because the annotations in the pull request description changed
(with .werft/ from main)

[werft-gitpod-dev-com]

started the job as gitpod-build-jx-attributed-team.4 because the annotations in the pull request description changed
(with .werft/ from main)

[werft-gitpod-dev-com]

started the job as gitpod-build-jx-attributed-team.5 because the annotations in the pull request description changed
(with .werft/ from main)

[werft-gitpod-dev-com]

started the job as gitpod-build-jx-attributed-team.6 because the annotations in the pull request description changed
(with .werft/ from main)

[werft-gitpod-dev-com]

started the job as gitpod-build-jx-attributed-team.7 because the annotations in the pull request description changed
(with .werft/ from main)

[werft-gitpod-dev-com]

started the job as gitpod-build-jx-attributed-team.8 because the annotations in the pull request description changed
(with .werft/ from main)

[andrew-farries]

Rather than leaving this unset in this case, should we explicitly fill in the ownerId?

[jankeromnes]

I believe leaving it unset for user attribution makes more sense:

• It can only be a teamId (the billing is either delegated to a specific team, or it falls back to the natural owner -- delegating to a different specific user would not make sense, right? 🤔)
• Setting it to possibly a userId makes the design more complex (need a second column attributedUserId, or maybe a prefix to the ID e.g. team-1324 vs user-1234)
• The team attribution chain goes through instance > workspace > project > team (some of the links can change over time so persisting the endpoint makes sense). User attribution is more direct (instance > workspace > owner) -- I don't think we can even get to a state where we don't know which user an instance belongs to.

[andrew-farries]

delegating to a different user would not make sense, right?

Yes, that's my understanding too.

[andrew-farries]

Tested this myself and saw the expected teamIds 👍

[jankeromnes]

Hmm, I just realized how similar this is to #10632 🤔

My initial reflex was to revert my PR again -- but then I realized my PR will allow to re-attribute usage to a different team (e.g. if you have a team with usage-based billing that wants to handle all your workspace usage regardless of project/team). So, maybe the two are actually complementary (and when we re-attribute, we might have to update the workspace metadata too 💡)