-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[server] Switch from Env to Config #4982
Conversation
f967e1a
to
c517b70
Compare
Removing the automatic review requests as this is still Draft. 😊 |
c517b70
to
81dc340
Compare
81dc340
to
35a2926
Compare
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.
Wow, quite a big change! 💪 I took a quick look, and didn't notice anything obviously broken.
What is the testing strategy to deploy this without accidentally breaking something subtle?
-
I like the old/new comparison check (did you try it by introducing some temporary small change?)
-
But I think we should also test this on staging really well (e.g. workspace backups, workspace downloads, prebuilds, the GitHub App, payments all could seem somewhat at risk and should be well tested)
Also, there are several import { Env }
and import { EnvEE }
left in various files. I know some of them are for comparison, but I'm not sure all remaining imports are still needed. Please double-check.
@@ -9,19 +9,20 @@ import { Branding } from "@gitpod/gitpod-protocol"; | |||
export namespace BrandingParser { |
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.
Do we still use this BrandingParser
? Can we remove it?
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.
see next comment.
disableDynamicAuthProviderLogin: boolean; | ||
|
||
// TODO(gpl) Can we remove this? | ||
brandingConfig: Branding; |
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.
Did you decide to keep it?
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.
Yes. There were some places where we use two fields. And I did not want to increase the complexity of this PR even more by a) making the decision here, and
b) changing that code/API as well.
This is actually the 2nd, bigger PR. The Config shape was already introduced before.
There are two things we can check: ManuallyAs ==> This helps to ensure that there is no drift in the values files (we have to slightly adjust those as well). AutomaticallyThere are three things we have to verify (in this review) to make this work:
==> This ensures that at least given the same input (chart), there is no difference between
Not sure what you mean with "temporary small changes"? I used this to find all discrepancies, so the "negative" as well as "positive" case works if that is what you mean.
If we do the two checks above really thoroughly I don't think this is necessary.
Did that, it's all for the comparison to work. 👍 |
35a2926
to
3c829c6
Compare
|
||
@injectable() | ||
export class GitpodCookie { | ||
@inject(Env) protected readonly env: Env; | ||
@inject(Config) protected readonly env: Config; |
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.
You called it config
everywhere else. Why not here?
|
||
@injectable() | ||
export class UserDeletionService { | ||
@inject(Env) protected readonly env: Env; | ||
@inject(Config) protected readonly config: Config; |
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.
Not used here. Should we push it down to subclass?
import { TraceContext } from "@gitpod/gitpod-protocol/lib/util/tracing"; | ||
|
||
@injectable() | ||
export class WorkspaceDeletionService { | ||
@inject(TracedWorkspaceDB) protected readonly db: DBWithTracing<WorkspaceDB>; | ||
@inject(StorageClient) protected readonly storageClient: StorageClient; | ||
@inject(Env) protected readonly env: Env; | ||
@inject(Config) protected readonly config: Config; |
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.
Not used here, either. Push down to subclass?
@inject(Config) protected readonly config: Config; | ||
@inject(Env) protected readonly env: Env; | ||
@inject(SessionHandlerProvider) protected sessionHandlerProvider: SessionHandlerProvider; | ||
@inject(Authenticator) protected authenticator: Authenticator; | ||
@inject(UserController) protected readonly userController: UserController; | ||
@inject(EnforcementController) protected readonly enforcementController: EnforcementController; |
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.
Why did you remove TheiaPluginController in this PR?
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.
We don't use it anymore.
Apart from some nitty comments /lgtm |
LGTM label has been added. Git tree hash: c6fa5afedfe24a0016883c22f118fd4dc854fd8f
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JanKoehnlein Associated issue: #4650 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes #4650.
Companion PR: https://github.com/gitpod-com/gitpod/pull/5862
TL;DR
This replaces
Env
(derived from env variables and relying on manual de-/serialization) withConfig
derived from a ConfigMap whose structure (mostly) matches thevalues.yaml
. To ensure we don't break stuff on deployment this comes with a restrictive safety check.About
This PR does away with the old
Env
/EnvEE
classes and replaces it with aConfig
shape which can be loaded from a config file of that exact same shape inserver-configmap.yaml
. In consequence a lot of the de-/serializing logic inEnv
got superfluous, and (nearly) all defaults moved tovalues.yaml:components.server
.For the initial deployment server on startups compares old and new config to make sure we didn't introduce an unwanted config drift.
Code-wise the most important parts are in:
-
server-configmap.yaml
-
server-deployment.yaml
-
values.yaml
-
config.ts
Besides this, changes fall into these categories:
values.yaml
andConfig
names map directlyToDo
devstaging
configstaging
configstaging
/production
valuesFuture work