[installer] support service type ClusterIP for proxy

[nandajavarma]

Description

Currently, there is no way to do a post-processing in KOTS like we suggest to do for replacing service type of proxy to ClusterIP. This PR introduces a new experimental field to the Config so users can provide a patch via the KOTS UI. The patch file can have the following structure:

experimental:
  webapp:
    proxy:
      serviceType: "ClusterIP" # allowed values are "ClusterIP", "LoadBalancer", "NodePort", "ExternalName" consistent with https://pkg.go.dev/k8s.io/api/core/v1#ServiceType

There is slight redundancy in the validation procedure at the moment(in the validation.go and service.go we check the allowed types). This is because we do not validate the config in KOTS as of now. We will remove this redundancy when we have better validation in place.

Related Issue(s)

Fixes #9981

How to test

Follow the instructions of this PR to setup a self-hosted installation with this change. Go to the Config tab of the KOTS UI. In the bottom you will see an Enable additional options section. Enable it, and copy paste the aforementioned YAML snippet to a file and upload it. Update the installment, and if you do a kubectl get svc proxy -n gitpod from the CLI you will see that it now has ClusterIP type.

Release Notes

NONE

Documentation

[adrienthebo]

I see this conditional doesn't have an else clause; if ServiceType is misspelled (eg cluterip) will this this code default to ServiceTypeLoadBalancer? Is there validation occurring in this pipeline?

[nandajavarma]

This is a great point Adrien! I agree that we can add a validation process. As of this implementation, it just defaults to LoadBalancer as set in this line.

About the validation, it is a great tip! We can leverage the existing validate cmd! I will do a follow-up PR for this!

[adrienthebo]

Copying my comment from Slack;

My philosophy on pull request review is to provide constructive feedback and make notes where I see potential changes/improvements/risks, but to grant approval as quickly so the author can land the work when they're ready and adopt feedback at their discretion. I think this is ready to ship but there might be a case where an additional conditional clause (or documentation) could be useful.

Since there are no blocking issues on this PR, is it following team policy to grant an approval here? And if we grant that approval, is that sufficient to merge the PR?

[adrienthebo]

LGTM! 👍

[corneliusludmann]

@adrienthebo:

My philosophy on pull request review is to provide constructive feedback and make notes where I see potential changes/improvements/risks, but to grant approval as quickly so the author can land the work when they're ready and adopt feedback at their discretion. I think this is ready to ship but there might be a case where an additional conditional clause (or documentation) could be useful.

100 % agree with this philosophy!

Since there are no blocking issues on this PR, is it following team policy to grant an approval here? And if we grant that approval, is that sufficient to merge the PR?

Approving PR is fine! ✔️ However, since we automatically merge PRs by a bot once all required approvals are given, you should add the hold label on this PR so that the author has the opportunity to address your comments. You can do this with this command in a comment:

/hold

The author just needs to remove the hold label or comment with /unhold and the PR will be merged.

(In this case, the PR still needs approval from Team WebApp. That's because this PR has not been merged yet automatically.)

[nandajavarma]

/unhold

[geropl]

✔️