Enable running DWO workspaces behind a proxy

[amisevsk]

What does this PR do?

• Add support for proxy configuration in DWO. Values are propagated as env vars to containers in workspaces
• Add support for reading cluster Proxy configuration on OpenShift
• Extend DevWorkspaceOperatorConfig CRD to include proxy configuration overrides

The git history for this PR is a little bit of a mess, so it may not make a huge amount of sense to go through it commit by commit, unless you want to follow my thought process.

What issues does this PR fix or reference?

Closes #678

Is it tested? How?

1. Set up crc with a proxy (see below)

2. Start DWO and verify that proxy configuration is read from the cluster -- should have log Resolved proxy configuration with the current configuration

3. Update the DWOC to add proxy settings, check that in-controller configuration is updated

4. Revert DWOC proxy settings and check that defaults from cluster are restored

5. Check behavior on minikube; should be able to set proxy settings in DWOC and defaults should be empty as there's no proxies.config.openshift.io CRD

Setting up crc with a proxy

Click to expand

This is just the process I followed, there's likely a better way. This assumes that initially crc is not started (might also need to crc delete) and that crc is running locally (i.e. not remotely)

1. Start Squid proxy in docker:

   docker run --detach \
     --name=squid \
     --restart=always \
     --publish 3128:3128 \
     --volume /srv/docker/squid/cache:/var/spool/squid3 \
     docker.io/sameersbn/squid:3.3.8-23

   Note: if the container above is stuck restarting, you may need to run sudo chcon -Rt svirt_sandbox_file_t /srv/docker/squid/cache

2. Start following Squid access logs to verify it's being used:

   docker exec -it squid tail -f /var/log/squid3/access.log

3. Configure crc to use proxy

   IP_ADDR=<address of current machine on lan>
   CRC_IP_ADDR=$(crc ip)
   crc config set http-proxy "http://${IP_ADDR}:3128"
   crc config set https-proxy "http://${IP_ADDR}:3128"
   crc config set no-proxy ${IP_ADDR}/24,${CRC_IP_ADDR},api.crc.testing,canary-openshift-ingress-canary.apps-crc.testing,console-openshift-console.apps-crc.testing,default-route-openshift-image-registry.apps-crc.testing,downloads-openshift-console.apps-crc.testing,oauth-openshift.apps-crc.testing
   

   (some of these no-proxy entries are probably unnecessary)

4. crc start

PR Checklist

• E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)
  • v8-devworkspace-operator-e2e: DevWorkspace e2e test
  • v8-che-happy-path: Happy path for verification integration with Che

[amisevsk]

I forgot to make DWO itself use the proxy, working on it.

[amisevsk]

Updated DWO to use proxy settings for its own HTTP clients. However, due to how the proxy is configured, these settings are only set once when the controller is being started, and changes to the proxy settings require a restart of the controller deployment. We can't restart the controller from itself easily, as the usual way of triggering a rollout (editing the pod's spec in the deployment) does not work in OLM, as the CSV owns the deployment and reverts changes.

I've updated the docs on the DevWorkspaceOperatorConfigs struct to reflect this.

[JPinkney]

Just tried on a cluster bot cluster and I'm able to see that the proxy configuration is resolved but when I look at the devworkspaceoperatorconfiguration I just have:

apiVersion: controller.devfile.io/v1alpha1
config:
  routing:
    defaultRoutingClass: basic
  workspace:
    imagePullPolicy: Always
kind: DevWorkspaceOperatorConfig
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"controller.devfile.io/v1alpha1","config":{"routing":{"clusterHostSuffix":null,"defaultRoutingClass":"basic"},"workspace":{"imagePullPolicy":"Always"}},"kind":"DevWorkspaceOperatorConfig","metadata":{"annotations":{},"name":"devworkspace-operator-config","namespace":"devworkspace-controller"}}

I'm assuming that the proxy settings are just stored internally in the operator unless they're overridden by the devworkspaceoperatorconfig?

Also the proxy settings seem to be propagated correctly to a devworkspace as well 👍

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amisevsk, JPinkney

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:

• OWNERS [JPinkney,amisevsk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[amisevsk]

I'm assuming that the proxy settings are just stored internally in the operator unless they're overridden by the devworkspaceoperatorconfig?

Yes -- in fact the DevWorkspaceOperatorConfig only stores manual overrides and does not need to exist at all for DWO to function. Its existence when testing changes is a side-effect of us wanting to automate config via env vars in the make rules resulting in it always being created even if defaults are used. If you check logs when starting DWO with the above DWOC, it should log something like Updated configuration to [(default config)].

[amisevsk]

/test v8-devworkspace-operator-e2e, v8-che-happy-path

[amisevsk]

/test v8-devworkspace-operator-e2e

[openshift-ci]

New changes are detected. LGTM label has been removed.

[amisevsk]

/test v8-devworkspace-operator-e2e

[amisevsk]

/test v8-devworkspace-operator-e2e