Skip to content
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

Merged
merged 5 commits into from
Sep 1, 2021
Merged

[server] Switch from Env to Config #4982

merged 5 commits into from
Sep 1, 2021

Conversation

geropl
Copy link
Member

@geropl geropl commented Jul 28, 2021

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) with Config derived from a ConfigMap whose structure (mostly) matches the values.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 a Config shape which can be loaded from a config file of that exact same shape in server-configmap.yaml. In consequence a lot of the de-/serializing logic in Env got superfluous, and (nearly) all defaults moved to values.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:

  • name normalizations so values.yaml and Config names map directly
  • grouping of some values where it made sense
  • removal of dead code and config
  • validation that checks that old and new config are identical

ToDo

  • see if Config/-Serialized should be reversed
  • make integration tests work again
  • compare and validate devstaging config
  • compare and validate staging config
  • adjust staging/production values

Future work

  • derive schema from shape and use that for validation

@jankeromnes
Copy link
Contributor

jankeromnes commented Aug 13, 2021

Removing the automatic review requests as this is still Draft. 😊

@geropl geropl marked this pull request as ready for review August 31, 2021 09:45
Copy link
Contributor

@jankeromnes jankeromnes left a 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 {
Copy link
Contributor

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?

Copy link
Member Author

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;
Copy link
Contributor

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?

Copy link
Member Author

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.

components/server/src/github/github-context-parser.spec.ts Outdated Show resolved Hide resolved
components/server/src/server.ts Outdated Show resolved Hide resolved
@geropl
Copy link
Member Author

geropl commented Aug 31, 2021

Wow, quite a big change!

This is actually the 2nd, bigger PR. The Config shape was already introduced before.

What is the testing strategy to deploy this without accidentally breaking something subtle?

There are two things we can check:

Manually

As Config has already been introduced, current prod/staging versions print there Config shape (the one derived from Env) to stdout on startup. Once we deployed the new version, we should compare those manually. But there have been a few additions, and also fixes to getConfigFromOldEnv, so this is not perfect.

==> This helps to ensure that there is no drift in the values files (we have to slightly adjust those as well).

Automatically

There are three things we have to verify (in this review) to make this work:

  1. env vars in server-deployment were not changed semantically
  2. env.ts was not changed semantically
  3. the getConfigFromOldEnv in config.ts is correct (mostly straight forward, should be easy to verify)

==> This ensures that at least given the same input (chart), there is no difference between Env and Config.

I like the old/new comparison check (did you try it by introducing some temporary small change?)

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.

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)

If we do the two checks above really thoroughly I don't think this is necessary.

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.

Did that, it's all for the comparison to work. 👍


@injectable()
export class GitpodCookie {
@inject(Env) protected readonly env: Env;
@inject(Config) protected readonly env: Config;
Copy link
Contributor

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;
Copy link
Contributor

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;
Copy link
Contributor

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;
Copy link
Contributor

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?

Copy link
Member Author

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.

@JanKoehnlein
Copy link
Contributor

Apart from some nitty comments

/lgtm

@roboquat
Copy link
Contributor

roboquat commented Sep 1, 2021

LGTM label has been added.

Git tree hash: c6fa5afedfe24a0016883c22f118fd4dc854fd8f

@roboquat
Copy link
Contributor

roboquat commented Sep 1, 2021

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[server] rewrite configuration to use a single config source
4 participants