[installer]: Allow replica counts to be specified for all components

[andrew-farries]

Description

One of the Webapp team's epics for Q2 is to use the Gitpod installer to deploy to Gitpod SaaS. In order to do that we will need to add additional configuration to the installer to make the output suitable for a SaaS deployment as opposed to a self-hosted deployment.

This PR adds the ability to configure the number of replicas for each component, rather than using to a hard-coded value of 1.

Related Issue(s)

Part of #9097

How to test

Create an installer config file containing this experimental section:

experimental:
  common:
    podConfig:
      server:
        replicas: 123
      content-service:
        replicas: 456

Get a versions.yaml for use with the installer:

docker run -it --rm "eu.gcr.io/gitpod-core-dev/build/versions:${version}" cat versions.yaml > versions.yaml

Then invoke the installer as:

installer render --debug-version-file versions.yaml --config /path/to/config --use-experimental-config

The rendered output will have the values from the config for the server and content-service components and the old default of 1 for all other components.

Release Notes

Allow replica counts for each component to be configurable through the installer

Documentation

None.

[mustard-mh]

this?

gitpod/install/installer/pkg/components/openvsx-proxy/statefulset.go

Lines 43 to 44 in 948ae51

	// todo(sje): receive config value
	Replicas: pointer.Int32(1),

[mrsimonemms]

@andrew-farries I hope I'm not coming across as Mr Negative, but I'm not sure this is the right approach. The experimental section is designed as "Gitpod SaaS-only" stuff but there are going to definitely be large self-hosted instances that will need to have multiple replicas. Generally speaking, we're not going to be supporting the use of the experimental section for self-hosted users (with some exceptions).

What might be a better approach is a more nuanced approach.

1. Adding a section to the main config, something like lite (I don't like that name, but can't think of anything better at the moment) where it defaults to false - if it's enabled, it puts everything into a single replica and if disabled it puts everything that can have multiple replicas to 2 (I believe there are deployments that cannot be replicated, but not sure)
2. Keep the experimental section as you've done for more fine-grained configuration

Then the value can be 1 or 2 for self-hosted users with a fairly small amount of configuration or n for SaaS users.

I'd also prefer that the experimental section didn't have a CommonConfig struct - I think it may be better having experimental.webapp.dashboard.podConfig.replicas = 2. That said, as this is for Gitpod SaaS, I'm not going to put up a fight if you want to stick with the current approach.

Also, we'll need to have some validation to make sure that the values are an integer. It's worth seeing what happens if you set the value to a string/boolean - hopefully it'll error/panic, but I don't think it would from reading the code

[easyCZ]

PR looks good, left a comment around general approach to config in go. Would you be able to please also add tests for the common.Replicas function? It's shared across many components and I'd rather we did have some tests to start with as we evolve it.

[geropl]

but I'm not sure this is the right approach. The experimental section is designed as "Gitpod SaaS-only" stuff but there are going to definitely be large self-hosted instances that will need to have multiple replicas

@mrsimonemms this approach was taken after a sync with @corneliusludmann last week which we scheduled for exactly this discussion. In general I agree: This is an option that we will need in for self-hosted at some point. But we decided to solve it this way, and put it into experimental because it's far easier to change afterwards. There is a whole host of config that could go into such a "common"/"generic" podConfig section. But unless we know how that should look like I suggest we decouple that decision from this PR/change. 👍

[geropl]

/hold

@andrew-farries Could you add unit tests as suggested by @easyCZ ? Thank you! 🙏

[easyCZ]

Approving as I'm happy with the changes. Left a couple of suggestions but up to you if you want to tackle them or how.

[andrew-farries]

this?

gitpod/install/installer/pkg/components/openvsx-proxy/statefulset.go

Lines 43 to 44 in 948ae51

	// todo(sje): receive config value
	Replicas: pointer.Int32(1),

Thanks, I missed this one.

[andrew-farries]

Also, we'll need to have some validation to make sure that the values are an integer. It's worth seeing what happens if you set the value to a string/boolean - hopefully it'll error/panic, but I don't think it would from reading the code

If the value for replicas is set to a string, the installer fails with:

[corneliusludmann]

Looks good to me.

Regarding experimental or not: As long as we don't have customers asking for this and we are not sure yet how exactly this config should look like it's much more convenient for us to use the experimental section as incubation for this config and move it to the general (public) section once we are fine with that and want to support this officially. That was the reason for the decision.

[andrew-farries]

/werft run with-clean-slate-deployment=true

👍 started the job as gitpod-build-af-installer-specify-replicacount.9
(with .werft/ from main)

[andrew-farries]

/werft run with-vm=true

👍 started the job as gitpod-build-af-installer-specify-replicacount.10
(with .werft/ from main)

[andrew-farries]

/werft run with-vm=true

👍 started the job as gitpod-build-af-installer-specify-replicacount.12
(with .werft/ from main)

[andrew-farries]

@easyCZ requested a re-review from you as I had to move the tests into an _test package (725fbd0) in order to address this comment.

[andrew-farries]

/unhold