Skip to content

[installer] set the ServiceType as LB for ws-proxy #8759

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 1 commit into from
Mar 29, 2022
Merged

Conversation

nandajavarma
Copy link
Contributor

Description

Currently, the type of the service created for ws-proxy is ClusterIP by default. When setting up in cloud in just the Workspace installation, this creates a requirement for having to post process the YAML to change the type to LoadBalancer. With this PR, the default value of ws-proxy service type is set as LoadBalancer when the installation is of the kind Workspace

Related Issue(s)

Fixes #7734

How to test

Set the value of kind in config file Workspace. Run the render command, installer render --config gitpod.config.yaml > gitpod.yaml. This will render Service definition of the app ws-proxy as type LoadBalancer

Release Notes

NONE

Documentation

No

@nandajavarma nandajavarma requested review from a team March 11, 2022 14:26
@github-actions github-actions bot added team: delivery Issue belongs to the self-hosted team team: workspace Issue belongs to the Workspace team labels Mar 11, 2022
@codecov
Copy link

codecov bot commented Mar 11, 2022

Codecov Report

Merging #8759 (6e5f2a7) into main (bc1e9fa) will decrease coverage by 1.13%.
The diff coverage is n/a.

❗ Current head 6e5f2a7 differs from pull request most recent head 3c93bec. Consider uploading reports for the commit 3c93bec to get more accurate results

@@            Coverage Diff             @@
##             main    #8759      +/-   ##
==========================================
- Coverage   12.31%   11.17%   -1.14%     
==========================================
  Files          20       18       -2     
  Lines        1161      993     -168     
==========================================
- Hits          143      111      -32     
+ Misses       1014      880     -134     
+ Partials        4        2       -2     
Flag Coverage Δ
components-gitpod-cli-app 11.17% <ø> (ø)
components-local-app-app-darwin-amd64 ?
components-local-app-app-darwin-arm64 ?
components-local-app-app-linux-amd64 ?
components-local-app-app-linux-arm64 ?
components-local-app-app-windows-386 ?
components-local-app-app-windows-amd64 ?
components-local-app-app-windows-arm64 ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
components/local-app/pkg/auth/pkce.go
components/local-app/pkg/auth/auth.go

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

// Hence we use LoadBalancer type for the service
if cfg.Config.Kind == config.InstallationWorkspace {
service.Spec.Type = corev1.ServiceTypeLoadBalancer
service.Annotations["cloud.google.com/neg"] = `{"exposed_ports": {"80":{},"443": {}}}`
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 need to hardcode google specific annotations here?

Copy link
Contributor

Choose a reason for hiding this comment

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

These annotations have been hardcoded for some time on the basis that a) they're ignored if not used and b) we don't really have an effective (and non-verbose) way of adding custom annotations to services. Elsewhere, there's also an annotation for external-dns with the same thinking

Copy link
Contributor

@mrsimonemms mrsimonemms left a comment

Choose a reason for hiding this comment

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

Looks good to me, save for the nit.

@@ -163,12 +163,21 @@ yq eval-all --inplace \
gitpod.yaml
```

Similarly, if you are doing a `Workspace` only install (specifying `Workspace`
as the kind in config) you might want to change the service type of `ws-proxy` to `ClusterIP`
instead of the default `LoadBalancer`. You can post-process the yaml to change that.
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: YAML, not yaml

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done!

princerachit
princerachit previously approved these changes Mar 14, 2022
Copy link
Contributor

@princerachit princerachit left a comment

Choose a reason for hiding this comment

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

I did not test the changes but code lgtm

yq eval-all --inplace \
'(select(.kind == "Service" and .metadata.name == "ws-proxy") | .spec.type) |= "ClusterIP"' \
gitpod.yaml
```
Copy link
Contributor

Choose a reason for hiding this comment

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

Off-topic: Do we have already an issue to get rid of this post-processing step and having a config value for the service type?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@corneliusludmann there is no such issue open specifically for making the service type configurable. I guess the question is do we plan on making this configurable, since our thought process was to not make it configurable.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm glad you brought that up. 🚀 Indeed, we decided like this in the past. However, 2 things have changed since then:

  • We introduced the experimental section. Everything that we won't support for some reason but need internally for SaaS should go there. We shouldn't need to rely on post-processing.
  • Since our official supported installation path will be the KOTS installation, we are a little more relaxed about the config surface.

What do you think, @mrsimonemms?

Copy link
Contributor

Choose a reason for hiding this comment

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

In principle, I'm happy for this to go into the experimental section. I think that should be a separate change though, as it will require discussion/agreement on the config surface change

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry for the inactivity on this issue. I have created this issue to track this requirement. Shall we merge this PR and continue the work there?

Copy link
Contributor

@princerachit princerachit left a comment

Choose a reason for hiding this comment

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

code changes lgtm. did not test this though

@Furisto
Copy link
Member

Furisto commented Mar 28, 2022

Hey @mrsimonemms, if I understood correctly you agree with the changes in this PR. If so, can you please approve it?

Copy link
Contributor

@mrsimonemms mrsimonemms left a comment

Choose a reason for hiding this comment

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

LGTM

@roboquat roboquat merged commit 4b35a6f into main Mar 29, 2022
@roboquat roboquat deleted the nvn/ws-proxy-lb branch March 29, 2022 07:56
@roboquat roboquat added the deployed: workspace Workspace team change is running in production label Mar 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: workspace Workspace team change is running in production release-note-none size/M team: delivery Issue belongs to the self-hosted team team: workspace Issue belongs to the Workspace team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[installer] Add support for Ingress traffic in cloud providers
6 participants