Skip to content

[usage] Implement GetBilledUsage RPC #11387

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 18, 2022
Merged

Conversation

andrew-farries
Copy link
Contributor

@andrew-farries andrew-farries commented Jul 14, 2022

Description

Implement the usage API GetBilledUsage RPC. Given an attribution ID, return usage records corresponding to that ID.

⚠️ No date filtering yet - this just returns all usage records for the attribution ID regardless of age. ⚠️

Related Issue(s)

Part of #9036

How to test

Unit tests for the RPC.

To test the API manually:

  1. Run the usage service locally against the database in the preview environment for this PR:
kubectl port-forward svc/mysql 3306:3306
cd components/usage
DB_HOST=localhost DB_USERNAME=gitpod DB_PASSWORD=<> DB_PORT=3306 go run . run
  1. Use a gRPC client like evans to run against the usage API:

image

Release Notes

NONE

Werft options:

  • /werft with-preview

@andrew-farries andrew-farries requested a review from a team July 14, 2022 15:38
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label Jul 14, 2022
@andrew-farries andrew-farries force-pushed the af/real-data-from-usage-api branch from ad5ad41 to 113617a Compare July 14, 2022 15:39
@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-af-real-data-from-usage-api.11 because the annotations in the pull request description changed
(with .werft/ from main)

@geropl geropl self-assigned this Jul 15, 2022
Comment on lines +38 to +48
AttributionId: string(usageRecord.AttributionID),
UserId: "",
TeamId: "",
WorkspaceId: "",
WorkspaceType: "",
ProjectId: "",
InstanceId: usageRecord.InstanceID.String(),
WorkspaceClass: "",
StartTime: timestamppb.New(usageRecord.StartedAt),
EndTime: endTime,
Credits: int64(usageRecord.CreditsUsed),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the missing fields here, I'm not sure how many we want to store in the usage table ourselves, vs how much we want to obtain by joining with the existing workspace table.

The motivation for storing usage was so that we don't need to recompute it on every query to the usage API, but as long as we have the instanceIds, we should be able to recover the workspace details here with joins.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I agree that this is the strategy we should follow. But WorkspaceClass and WorkspaceType should definitely in here, because they are relevant for the billing parts.
And regarding the hierachy-tuple TeamId-ProjectId-UserId-WorkspaceId: I think being able to directly correlate this entry (without the indirection over WorkspaceInstance) is valuable as well, and helps to "place this session on the map" if you will. I think we should have those, too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI We talked in sync, and agreed to wait for @easyCZ and his opinion. 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, we should have first-class fields (these are mostly the ones we want to group-by in our views or are important enough to show in list views.

All the fields above meet this first-class definition so I would keem them as is. We should populate them directly from the usage report.

For any extra fields, we should call into WorkspaceInstance for details, or setup a service which pre-joins these for us.

@geropl
Copy link
Member

geropl commented Jul 15, 2022

@andrew-farries I tested with evans but got an SEGFAULT. I have not clue how to debug that.

Also, wrt to the fields discussion: If we ship less fields then currently defined we should adjust the parsing code here as well.

@andrew-farries
Copy link
Contributor Author

@andrew-farries I tested with evans but got an SEGFAULT. I have not clue how to debug that.

This appears to be a regression between evans v0.10.6 and v0.10.7 released yesterday.

Using v0.10.6 works as expected.

@andrew-farries
Copy link
Contributor Author

PR to add a working version to the dev image here: #11413

@andrew-farries andrew-farries changed the base branch from main to af/integer-credit-values-in-usage-store July 18, 2022 07:35
@andrew-farries andrew-farries force-pushed the af/real-data-from-usage-api branch from 113617a to 3ee2685 Compare July 18, 2022 07:39
@andrew-farries
Copy link
Contributor Author

andrew-farries commented Jul 18, 2022

/werft run with-clean-slate-deployment=true

👍 started the job as gitpod-build-af-real-data-from-usage-api.13
(with .werft/ from main)

@andrew-farries
Copy link
Contributor Author

/hold as this is now based on #11429

@@ -37,3 +38,14 @@ func CreateUsageRecords(ctx context.Context, conn *gorm.DB, records []WorkspaceI

return db.CreateInBatches(records, 1000).Error
}

func GetUsage(ctx context.Context, conn *gorm.DB, attributionId AttributionID) ([]WorkspaceInstanceUsage, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func GetUsage(ctx context.Context, conn *gorm.DB, attributionId AttributionID) ([]WorkspaceInstanceUsage, error) {
func ListUsage(ctx context.Context, conn *gorm.DB, attributionId AttributionID) ([]WorkspaceInstanceUsage, error) {

It returns a collection of records. Get is often used to mean a single record.

)

var _ v1.UsageServiceServer = (*UsageService)(nil)

type UsageService struct {
conn *gorm.DB
v1.UnimplementedUsageServiceServer
}

func (us *UsageService) GetBilledUsage(ctx context.Context, in *v1.GetBilledUsageRequest) (*v1.GetBilledUsageResponse, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't spot this before but I'd call the RPC ListUsage because it returns a collection of records

Copy link
Contributor Author

@andrew-farries andrew-farries Jul 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ListUsage or ListBilledUsage?

Copy link
Member

@easyCZ easyCZ Jul 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess ListBilledUsage to keep it similar. But generally, a Service should only return one type of Resource (less important for private APIs but for Public ones, it helps with UX). So here, we'd normally have a BilledUsageService, which returns BilledUsage records but no point changing now.

@roboquat roboquat added size/XXL and removed size/L labels Jul 18, 2022
@andrew-farries andrew-farries force-pushed the af/real-data-from-usage-api branch 2 times, most recently from 419689b to 7a814fd Compare July 18, 2022 10:31
@andrew-farries andrew-farries changed the base branch from af/integer-credit-values-in-usage-store to main July 18, 2022 11:34
@andrew-farries andrew-farries force-pushed the af/real-data-from-usage-api branch 2 times, most recently from fed680f to 5156661 Compare July 18, 2022 11:39
@andrew-farries andrew-farries force-pushed the af/real-data-from-usage-api branch from 5156661 to a86efd2 Compare July 18, 2022 11:51
@andrew-farries
Copy link
Contributor Author

/unhold

@roboquat roboquat merged commit e238535 into main Jul 18, 2022
@roboquat roboquat deleted the af/real-data-from-usage-api branch July 18, 2022 11:57
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels Jul 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed Change is completely running in production release-note-none size/XXL team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants