-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[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
Conversation
ad5ad41
to
113617a
Compare
started the job as gitpod-build-af-real-data-from-usage-api.11 because the annotations in the pull request description changed |
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), |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. 👍
There was a problem hiding this comment.
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.
@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. |
This appears to be a regression between Using |
PR to add a working version to the dev image here: #11413 |
113617a
to
3ee2685
Compare
/werft run with-clean-slate-deployment=true 👍 started the job as gitpod-build-af-real-data-from-usage-api.13 |
/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) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
components/usage/pkg/apiv1/usage.go
Outdated
) | ||
|
||
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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ListUsage
or ListBilledUsage
?
There was a problem hiding this comment.
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.
419689b
to
7a814fd
Compare
fed680f
to
5156661
Compare
5156661
to
a86efd2
Compare
/unhold |
Description
Implement the usage API
GetBilledUsage
RPC. Given an attribution ID, return usage records corresponding to that ID.Related Issue(s)
Part of #9036
How to test
Unit tests for the RPC.
To test the API manually:
evans
to run against the usage API:Release Notes
Werft options: