[openVSXProxy] Mark the usage of PVC optional

[Pothulapati]

Description

Currently, OpenVSXProxy is the only non-optional component that needs PVC's to get things working. The usage of a PVC in AWS reference architecture, means that components can't get restarted in a different zone anymore as PVC's with EBS are specific to a zone.

As EKS reference architecture does not enable any other component that uses PVC's (i.e minio), This is a problem specific to OpenVSXProxy.

By disabling this, OpenVSXProxy's redis now will have lost the cache once a restart occurs which does not seems like a big deal for self-hosted customers.

Signed-off-by: Tarun Pothulapati [email protected]

Related Issue(s)

Fixes #14529

How to test

Release Notes

[openVSXProxy] Mark the usage of PVC optional

Documentation

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-large-vm
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh

[Pothulapati]

/hold as we need to either update ops or switch the condition to be enabled by default

[Pothulapati]

/werft run

👍 started the job as gitpod-build-tar-openvsxproxy-pvc-optional.1
(with .werft/ from main)

[iQQBot]

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

Lines 133 to 136 in 8802661

	}, {
	Name: "redis-data",
	MountPath: "/data",
	}},

Is it ok the pod has mount but don't have pvc or volumes ?

[Pothulapati]

@iQQBot You are right, We need a emptyDir volume which I just added! 👀

[iQQBot]

change it to DisablePVC looks weird, it required user use experimental config.

[Pothulapati]

@iQQBot Yes, Because this issue is specific to EKS and with GKE this seems to done automatically and chanding existing functionality did not seem like a great idea! 👀

[iQQBot]

@iQQBot Yes, Because this issue is specific to EKS and with GKE this seems to done automatically and chanding existing functionality did not seem like a great idea! 👀

What I mean is that users should not use experimental config, maybe move to the regular config?

[Pothulapati]

@iQQBot Moved the config into OpenVSX.Proxy.DisablePVC instead of being in experimental

[iQQBot]

LGTM

[mrsimonemms]

Have you tried disabling the PVC from an existing installation? I recall we had lots of issues when amending a PVC on the in-cluster storage (I think) which is why we never made it any bigger - wondered if removing the PVC causes any issues

[mrsimonemms]

/werft run publish-to-kots

👍 started the job as gitpod-build-tar-openvsxproxy-pvc-optional.4
(with .werft/ from main)

[mrsimonemms]

/hold

Left a comment that I would prefer if it were reviewed, but happy for you to merge if you don't think it necessary/relevant

[Pothulapati]

I recall we had lots of issues when amending a PVC on the in-cluster storage (I think) which is why we never made it any bigger - wondered if removing the PVC causes any issues

@mrsimonemms I haven't tested it on changing an existing cluster but considering that its just a statefulset that won't have a PVC anymore, This shouldn't be complex is my guess. 🤔

[Pothulapati]

/unhold