Skip to content

[installer] Make all config values with sensible defaults optional #8267

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

Closed
corneliusludmann opened this issue Feb 17, 2022 · 1 comment · Fixed by #8401
Closed

[installer] Make all config values with sensible defaults optional #8267

corneliusludmann opened this issue Feb 17, 2022 · 1 comment · Fixed by #8401
Assignees
Labels
component: install Terraform installation scripts, helm charts, installer images team: delivery Issue belongs to the self-hosted team

Comments

@corneliusludmann
Copy link
Contributor

In my opinion, we should make all config values that have sensible default values optional in the config file. E.g., it should be totally fine to use a config like this:

apiVersion: v1
domain: gitpod.my-domain.example

That would also make generating config values for e.g. replicated easier.

see also #8266 (comment)

@corneliusludmann corneliusludmann added component: install Terraform installation scripts, helm charts, installer images team: delivery Issue belongs to the self-hosted team labels Feb 17, 2022
@corneliusludmann corneliusludmann added this to the release/2022.02 milestone Feb 17, 2022
@Pothulapati
Copy link
Contributor

@corneliusludmann Totally agree with the suggestion! I was confused initially too, and why I need to pass all the defaults even when its the init command that is providing me those values.

We should make those optional, and override them if they are passed by the user! I'll start working on this!

@Pothulapati Pothulapati self-assigned this Feb 17, 2022
Pothulapati added a commit that referenced this issue Feb 23, 2022
Fixes #8267

Currently, Users run `init` command first, update it and
pass full config to `render` to generate Kubernetes manifests. The
passage of `-c` is a requirement here, and users can't skip it.

This PR makes the passage of `config` to `render` optional, and
flexible. This means
- Users can skip `-c` entirely, in which case we use the default
  values on the default config version for that installer binary
- Users can selectively override fields and *thus no need to pass full
  config* all the time. This means `-c` flag acts as a flag through
  which they can override the default fields.

For the second case, When a user explicitely sets the `apiVersion`
field in the passed config, we use the default values for that
version. If no `apiVersion` is passed, we override the passed config
onto the default values on the default config version for that
installer binary.

After this change, For users This means that they only store and use
the config that has their changes only (on the default config), and
not the entire config.

Signed-off-by: Tarun Pothulapati <[email protected]>
Pothulapati added a commit that referenced this issue Feb 23, 2022
Fixes #8267

Currently, Users run `init` command first, update it and
pass full config to `render` to generate Kubernetes manifests. The
passage of `-c` is a requirement here, and users can't skip it.

This PR makes the passage of `config` to `render` optional, and
flexible. This means
- Users can skip `-c` entirely, in which case we use the default
  values on the default config version for that installer binary
- Users can selectively override fields and *thus no need to pass full
  config* all the time. This means `-c` flag acts as a flag through
  which they can override the default fields.

For the second case, When a user explicitely sets the `apiVersion`
field in the passed config, we use the default values for that
version. If no `apiVersion` is passed, we override the passed config
onto the default values on the default config version for that
installer binary.

After this change, For users This means that they only store and use
the config that has their changes only (on the default config), and
not the entire config.

Signed-off-by: Tarun Pothulapati <[email protected]>
Pothulapati added a commit that referenced this issue Feb 23, 2022
Fixes #8267

Currently, Users run `init` command first, update it and
pass full config to `render` to generate Kubernetes manifests. The
passage of `-c` is a requirement here, and users can't skip it.

This PR makes the passage of `config` to `render` optional, and
flexible. This means
- Users can skip `-c` entirely, in which case we use the default
  values on the default config version for that installer binary
- Users can selectively override fields and *thus no need to pass full
  config* all the time. This means `-c` flag acts as a flag through
  which they can override the default fields.

For the second case, When a user explicitely sets the `apiVersion`
field in the passed config, we use the default values for that
version. If no `apiVersion` is passed, we override the passed config
onto the default values on the default config version for that
installer binary.

After this change, For users This means that they only store and use
the config that has their changes only (on the default config), and
not the entire config.

Signed-off-by: Tarun Pothulapati <[email protected]>
Pothulapati added a commit that referenced this issue Feb 24, 2022
Fixes #8267

Currently, Users run `init` command first, update it and
pass full config to `render` to generate Kubernetes manifests. The
passage of `-c` is a requirement here, and users can't skip it.

This PR makes the passage of `config` to `render` optional, and
flexible. This means
- Users can skip `-c` entirely, in which case we use the default
  values on the default config version for that installer binary
- Users can selectively override fields and *thus no need to pass full
  config* all the time. This means `-c` flag acts as a flag through
  which they can override the default fields.

For the second case, When a user explicitely sets the `apiVersion`
field in the passed config, we use the default values for that
version. If no `apiVersion` is passed, we override the passed config
onto the default values on the default config version for that
installer binary.

After this change, For users This means that they only store and use
the config that has their changes only (on the default config), and
not the entire config.

Signed-off-by: Tarun Pothulapati <[email protected]>
Pothulapati added a commit that referenced this issue Feb 24, 2022
Fixes #8267

Currently, Users run `init` command first, update it and
pass full config to `render` to generate Kubernetes manifests. The
passage of `-c` is a requirement here, and users can't skip it.

This PR makes the passage of `config` to `render` optional, and
flexible. This means
- Users can skip `-c` entirely, in which case we use the default
  values on the default config version for that installer binary
- Users can selectively override fields and *thus no need to pass full
  config* all the time. This means `-c` flag acts as a flag through
  which they can override the default fields.

For the second case, When a user explicitely sets the `apiVersion`
field in the passed config, we use the default values for that
version. If no `apiVersion` is passed, we override the passed config
onto the default values on the default config version for that
installer binary.

After this change, For users This means that they only store and use
the config that has their changes only (on the default config), and
not the entire config.

Signed-off-by: Tarun Pothulapati <[email protected]>
roboquat pushed a commit that referenced this issue Feb 24, 2022
Fixes #8267

Currently, Users run `init` command first, update it and
pass full config to `render` to generate Kubernetes manifests. The
passage of `-c` is a requirement here, and users can't skip it.

This PR makes the passage of `config` to `render` optional, and
flexible. This means
- Users can skip `-c` entirely, in which case we use the default
  values on the default config version for that installer binary
- Users can selectively override fields and *thus no need to pass full
  config* all the time. This means `-c` flag acts as a flag through
  which they can override the default fields.

For the second case, When a user explicitely sets the `apiVersion`
field in the passed config, we use the default values for that
version. If no `apiVersion` is passed, we override the passed config
onto the default values on the default config version for that
installer binary.

After this change, For users This means that they only store and use
the config that has their changes only (on the default config), and
not the entire config.

Signed-off-by: Tarun Pothulapati <[email protected]>
Repository owner moved this from ⚒In Progress to ✨Done in 🚚 Security, Infrastructure, and Delivery Team (SID) Feb 24, 2022
mustard-mh pushed a commit that referenced this issue Feb 28, 2022
Fixes #8267

Currently, Users run `init` command first, update it and
pass full config to `render` to generate Kubernetes manifests. The
passage of `-c` is a requirement here, and users can't skip it.

This PR makes the passage of `config` to `render` optional, and
flexible. This means
- Users can skip `-c` entirely, in which case we use the default
  values on the default config version for that installer binary
- Users can selectively override fields and *thus no need to pass full
  config* all the time. This means `-c` flag acts as a flag through
  which they can override the default fields.

For the second case, When a user explicitely sets the `apiVersion`
field in the passed config, we use the default values for that
version. If no `apiVersion` is passed, we override the passed config
onto the default values on the default config version for that
installer binary.

After this change, For users This means that they only store and use
the config that has their changes only (on the default config), and
not the entire config.

Signed-off-by: Tarun Pothulapati <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: install Terraform installation scripts, helm charts, installer images team: delivery Issue belongs to the self-hosted team
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants