[Self-Hosted] minio PVC defaults to 8Gi only

[geropl]

We should fix two things:

• choose a sane default that does work for some minimal testing (maybe 50Gi?)
• provide means for users to (optionally) configure it without yqing the resulting yaml

[mrsimonemms]

Rather than exposing loads of config for dependencies in the Installer, could you configure a separate Minio installation on your cluster (with Helm) and the connect Gitpod to it as an S3 store?

We definitely need to document this better, but that's my thoughts on more fine-grained config of our in-cluster dependencies

[geropl]

We definitely need to document this better, but that's my thoughts on more fine-grained config of our in-cluster dependencies

Maybe documentation is already it, or making more clear that this is really not recommended to use in-cluster minio. But people tend to forget what they configured during installation time, and later are upset that their Gitpod does not work. 😕

Rather than exposing loads of config for dependencies in the Installer, ...

Just wrote it up this way ("add to our config") because that was the immediate reaction from the user: He did not care at all if minio is one of our dependencies or our own code, but expected it to be configurable from our interface - because it's part of the "Gitpod system". (Maybe this expectation stems from helm where it's possible to configure all dependencies 🤷 )

[lucasvaltl]

@mrsimonemms could you check wether we have a solution for this - @Pothulapati do you have or need this in the local preview?

[mrsimonemms]

I'll make a change to the default value to 50GB as @geropl requested. I also think it's worth documenting how to create your own registry/database/minio on your own cluster if you want to customise things, but don't want to use an external service.

[mrsimonemms]

I've changed my mind on this. I've just run an experiment where I've changed from 8Gi to 50Gi on a running instance and I get the following error:

Error from server (Forbidden): error when applying patch:
{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"PersistentVolumeClaim\",\"metadata\":{\"annotations\":{},\"labels\":{\"app.kubernetes.io/instance\":\"Minio\",\"app.kubernetes.io/managed-by\":\"Helm\",\"app.kubernetes.io/name\":\"minio\",\"helm.sh/chart\":\"minio-11.6.3\"},\"name\":\"minio\",\"namespace\":\"gitpod\"},\"spec\":{\"accessModes\":[\"ReadWriteOnce\"],\"resources\":{\"requests\":{\"storage\":\"50Gi\"}}}}\n"}},"spec":{"resources":{"requests":{"storage":"50Gi"}}}}
to:
Resource: "/v1, Resource=persistentvolumeclaims", GroupVersionKind: "/v1, Kind=PersistentVolumeClaim"
Name: "minio", Namespace: "gitpod"
for: "STDIN": persistentvolumeclaims "minio" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize

My feeling is that we can catch all this with documentation as above. We probably could solve this issue if we had to, but in-cluster dependencies are meant to be used as conveniences to get running quickly not as long-term/high-performance solutions

[dimm0]

Rather than exposing loads of config for dependencies in the Installer, could you configure a separate Minio installation on your cluster (with Helm) and the connect Gitpod to it as an S3 store?

We definitely need to document this better, but that's my thoughts on more fine-grained config of our in-cluster dependencies

I'm really trying to deploy gitpod in my own cluster with my own registry and S3 storage that I already have and that work really well.

But... GitLab registry is unsupported, ceph S3 is unsupported in all variants (as blob storage and as backend for containers)

So I'm stuck with manually deploying a layer on top of other stuff... And I have to do it myself, instead of using gitpod's built-in ones