[usage] Implement initial gRPC API

[andrew-farries]

Description

#11221 added the .proto definitions for a placeholder gRPC API for the usage component.

This PR implements the server side of that placeholder API.

Also updates the installer to deploy config for the usage component so that it serves gRPC and adds a k8s service through which it can be accessed.

Related Issue(s)

Fixes #10324

How to test

• Run the usage service locally:

cd components/usage
leeway build .:init-testdb
DB_USERNAME=gitpod DB_PORT=23306 DB_PASSWORD=test go run . run

• Access the gRPC API (using evans):

evans -p 9001 -r repl
> package usage.v1
> show services

The placeholder API is shown:

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview

/hold

[easyCZ]

I think you should be able to omit this

[andrew-farries]

The Go struct that gets serialized to create this config is this one:

gitpod/components/common-go/baseserver/config.go

Line 18 in 8639720

TLS *TLSConfiguration `json:"tls" yaml:"tls"`

The TLS field doesn't specify omitempty so it's always unmarshalled to nil.

I think the TLS field should specify omitempty, then we can get rid of this line as you suggest.

[easyCZ]

Makes sense, wanna make that change?

[andrew-farries]

I'm going to do it in another PR because doing so will tag the workspace team into this one as reviewers which doesn't seem worth it.

[andrew-farries]

here: #11240

[mrsimonemms]

Approving as self-hosted wrongly marked as owner on these files

[geropl]

@andrew-farries With this being "blocked" I have a hard time understanding what state this PR is in. 😕 It is ready to be merged (marked as "ready for review" + approved)? Also, I did not notice any reason for the hold…..?

[andrew-farries]

@andrew-farries With this being "blocked" I have a hard time understanding what state this PR is in. 😕 It is ready to be merged (marked as "ready for review" + approved)? Also, I did not notice any reason for the hold…..?

I'm not sure what you mean by "blocked" here.

The PR is ready to review. Only caveat is that ca861c2 was already reviewed in #11236 and 7b25556, 22f51dd were reviewed in #11240.

Maybe stacked PRs here are causing more confusion than they are worth.

I've removed the hold - there was no reason for it. I generally like to add it to PRs so I can be in control of when it gets merged eg if there are any "optional" changes required from reviewers.

/unhold

[easyCZ]

Personally, I'd recommend using stacked PRs as a Queue only and not to merge later PRs into their predecestor, it makes it easier to follow what needs reviewing. With that, I'd also keep any follow-on PRs as draft until they can actually be reviewed.