Enable PersistentVolumeClaim name configuration variable

[yagouam]

Hello, I hope this is the right way to trace issues, if not let me know how could I ask for new features

We are trying to enable minio in our kubernetes environment, and as developers we have no permissions for creating PVC and our system administrator teammates want a different name for each PVC per environment.

Currently we cannot modify the PVC name, it is hardcoded in tutorminio/patches/k8s-volumes.

We've tryed to use the "k8s-override" hook to modify the previous file but it throws an error while launching

It would be nice to have a configuration variable such as MINIO_PVC_NAME to modify PVC name for each environment.

Thanks in advance

Kind regards!

[DawoudSheraz]

Hi, can you provide further details of the errors you encountered when using k8s-override?

[yagouam]

Hello @DawoudSheraz

Of course. The error is the following:

error: no matches for Id PersistentVolumeClaim.v1.[noGrp]/pvc-miniopv-openedx-pre.[noNs]; failed to find unique target for patch PersistentVolumeClaim.v1.[noGrp]/pvc-miniopv-openedx-pre.[noNs]
Error: Command failed with status 1: kubectl apply --kustomize /opt/openedx/manifests-uamx/environments/openedx-stage/env --dry-run=server --validate=true

Our override.yml is like this (similar to minio's volume.py but changing the name of the pvc):

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-miniopv-openedx-pre
  labels:
    app.kubernetes.io/component: volume
    app.kubernetes.io/name: minio
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

And if I run kubectl get pvc the pvc information is:

NAME                      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-miniopv-openedx-pre   Bound     pvc-XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX   5Gi        RWO            XXXXXXXX   6d21h

[yagouam]

I have to say we are looking forward for another solution, trying to convince our engineers to bring us permissions to create and modify pvcs dynamically (what I understand is the common behaviour). Just in case I would like to try this path, but I am not very enthusiastic as I think we'll encounter other blockers due to permission issues...

[Faraz32123]

Hey @yagouam, hope you are doing well.
So regarding the above error that you guys were facing while changing the name for the PVC.
It occurred because you are trying to override the name of the PVC(that name/PVC doesn't exists in volumes.yml) using k8s-override patch and kubectl apply --kustomize command fails while overriding the volumes.yml.

error: no matches for Id PersistentVolumeClaim.v1.[noGrp]/pvc-miniopv-openedx-pre.[noNs]; failed to find unique target for patch PersistentVolumeClaim.v1.[noGrp]/pvc-miniopv-openedx-pre.[noNs]
Error: Command failed with status 1: kubectl apply --kustomize /opt/openedx/manifests-uamx/environments/openedx-stage/env --dry-run=server --validate=true

So, what u can do is

• use k8s-volumes patch in your plugin or custom plugin that u have made that will look like below. It will create a new PVC with your desired name.

{% if not MINIO_GATEWAY %}
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-miniopv-openedx-pre
  labels:
    app.kubernetes.io/component: volume
    app.kubernetes.io/name: minio
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
{% endif %}

• use another patch k8s-override in which u will link/override minio deployment in deployments.yml with your new pcv like below.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: minio
  labels:
    app.kubernetes.io/name: minio
spec:
  template:
    spec:
      {% if not MINIO_GATEWAY %}
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: pvc-miniopv-openedx-pre
      {% endif %}

Note: You can't change name of the PVC as code is now. With your proposed approach with new variable settings, it will create a new PVC(it won't override the name if someone had already run the launch and created the PVC with default name). So above seems to be the safe approach. Don't forget to migrate data from older PVC to newer PVC if you guys want to change the name for the PVC in your environment and delete the older PVC.

[yagouam]

Hi @Faraz32123 , thanks for your response!

You are right, the error was in trying to modify the PVC once created, a forbidden behaviour in kubernetes.

We finally created a fork of this plugin enabling multiple customizations in the volume patch, such as namespace, storageclass, and storage, because our environment does not provide a storageclass by default. Furthermore, we need to target a storageclass that provides a "Retain" ReclaimPolicy to prevent deleting the data accidentally, so even if we have a "default" SC in the cluster it wont't meet our needs as we share the cluster with multiple applications.

We can close this issue as is it seems to be a particular problem of us.

Thanks for supporting!