chore: track usage of organizations in telemetry #16323
Conversation
…eference their orgs
There was a problem hiding this comment.
I see the initialization order of IDP sync in server.go
Telemetry happens before coderd, and coderd inits the IDPsync.
I also see the import cycle.
If you want to fix the import cycle, we can just move ReportCLITelemetry to the telemetry package. It is the only code in httpmw that requires telemetry, and it does not need any other httpmw code.
The initialization order is a bit tricky, as you mentioned. I do not know if moving the idp sync init outside the coderd.New would cause issues.
In general, I wish our init code was easier to read and maintain 😢
I'll defer to your judgement. Since this is just telemetry, and the implementation will be relatively static, I am fine with this 👍
| // Warning: When an organization is deleted, it's completely removed from | ||
| // the database. It will no longer be reported, and there will be no other | ||
| // indicator that it was deleted. This requires special handling when | ||
| // interpreting the telemetry data later. |
There was a problem hiding this comment.
We do intend to fix that with soft deletes.
|
Note: |
To avoid code duplication, we'd have to fix both the import cycle and the init order, and the latter is tricky. I'd rather not do that now, but it'd be great to eventually fix it. |
Addresses coder/internal#317.
Changes
Requirements are quoted below:
Adds the Organization entity to telemetry.
All resources that reference an org already report the org id to telemetry. Adds a test to check that.
Adds the
IDPOrgSyncboolean field to the Deployment entity.Implementation of the org sync check
While there's an
OrganizationSyncEnabledmethod on the IDPSync interface, I decided not to use it directly and implemented a counterpart just for telemetry purposes. It's a compromise I'm not happy about, but I found that it's a simpler approach than the alternative. There are multiple reasons:OrganizationSyncEnabledfunction at the time of instantiating the telemetry object, because our server initialization logic depends on the telemetry object being created before the IDPSync object.OrganizationSyncEnabled, we have to refactor the initialization logic of the telemetry object itself to avoid a race condition where the first telemetry report is performed without a valid reference.I actually implemented that approach in #16307, but realized I'm unable to fully test it. It changed the initialization order in the server command, and I wanted to test our CLI with Org Sync configured with a premium license. As far as I'm aware, we don't have the tooling to do that. I couldn't figure out a way to start the CLI with a mock license, and I didn't want to go down further into the refactoring rabbit hole.
So I decided that reimplementing the org sync checking logic is simpler.