Skip to content

[baseserver] Support common config struct #9999

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 6 commits into from
May 16, 2022
Merged

[baseserver] Support common config struct #9999

merged 6 commits into from
May 16, 2022

Conversation

csweichel
Copy link
Contributor

@csweichel csweichel commented May 13, 2022

Description

This PR refactors baseserver so that it's easy to integrate into the existing components, all the while harmonising the RPC/debug/HTTP configuration surface.

There's a stack of follow-up PRs which demonstrate the use of these changes in the real world:

How to test

See unit tests

Release Notes

NONE

/werft no-preview

@csweichel csweichel force-pushed the cw/baseserver-cfg branch from 3c5fdf7 to 3b6aa28 Compare May 13, 2022 13:02
specifically debug, health and readiness
@csweichel csweichel force-pushed the cw/baseserver-cfg branch 6 times, most recently from a735ea1 to 7e6cd6e Compare May 13, 2022 14:07
@csweichel csweichel force-pushed the cw/baseserver-cfg branch 3 times, most recently from 6c600ef to 1940499 Compare May 13, 2022 14:36
@csweichel csweichel marked this pull request as ready for review May 13, 2022 15:37
@csweichel csweichel requested review from a team May 13, 2022 15:37
@github-actions github-actions bot added team: delivery Issue belongs to the self-hosted team team: webapp Issue belongs to the WebApp team team: workspace Issue belongs to the Workspace team labels May 13, 2022
Copy link
Contributor

@jenting jenting left a comment

Choose a reason for hiding this comment

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

/lgtm

Copy link
Member

@easyCZ easyCZ left a comment

Choose a reason for hiding this comment

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

Nice, makes sense. Left a couple of comments.

In general, this PR could've been split over multiple PRs to make the review more digestible.

}
}

func MustFindFreePort(t *testing.T) int {
Copy link
Member

Choose a reason for hiding this comment

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

I think this is possibly racy. We're binding a socket to find out it's free, but then we release it immediately and again re-bind during server startup. During tests, we can have a number of servers running concurrently and do not have guarantees in which order they will execute.

I think here we should either make it so we always require an explicit port and never assign one automatically, it then becomes the Test's problem to find an available port, or support binding the socket only once during server startup.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is indeed racy. Short of exposing the listener through API I fret there's no good way to not make it racy.

I think here we should either make it so we always require an explicit port and never assign one automatically

That's what's implemented now. In addition there's the helper func to try and find a free port. I'd vote for going with this for - if the raciness proves to be a problem in practice, we extend the API so that tests can hand in a bound listener.

Copy link
Member

Choose a reason for hiding this comment

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

Let's see how this goes. I think testing with a baseserver is already an improvement compared to what we have today for most things. We can always follow-up on this.

return s.cfg.httpPort >= 0
func (s *builtinServices) Close() error {
var eg errgroup.Group
eg.Go(func() error { return s.Debug.Close() })
Copy link
Member

Choose a reason for hiding this comment

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

Neat! This does however not ensure that the Debug server is closed last. In general, it's beneficial to ensure it's last as it allows you to get the most metrics out of the system before it shuts down, and that way it also does contain metrics from the http/grpc servers shutting down.

@easyCZ easyCZ self-assigned this May 16, 2022
@csweichel
Copy link
Contributor Author

csweichel commented May 16, 2022

/werft run

👍 started the job as gitpod-build-cw-baseserver-cfg.15
(with .werft/ from main)

@csweichel
Copy link
Contributor Author

csweichel commented May 16, 2022

/werft run

👍 started the job as gitpod-build-cw-baseserver-cfg.16
(with .werft/ from main)

@csweichel
Copy link
Contributor Author

I've addressed the comments, and rebased the stacked PRs.
#10005 is ready for review now.

@@ -10,10 +10,6 @@ import (

func service(ctx *common.RenderContext) ([]runtime.Object, error) {
return common.GenerateService(Component, map[string]common.ServicePort{
DebugPortName: {
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for removing this. It was the next for me to clean up after I landed the "debug/built-in server" last Friday.

@roboquat roboquat merged commit 1dd74d3 into main May 16, 2022
@roboquat roboquat deleted the cw/baseserver-cfg branch May 16, 2022 07:53
@roboquat roboquat added the deployed: webapp Meta team change is running in production label May 17, 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 release-note-none size/XXL team: delivery Issue belongs to the self-hosted team team: webapp Issue belongs to the WebApp team team: workspace Issue belongs to the Workspace team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants