can't deploy at local kubernetes (unbound immediate PersistentVolumeClaims) about mongodb-kubernetes-operator HOT 5 CLOSED

Hello @nikosece and thanks for your patience.

We had some bugs around merging custom specs for volumes claims which we hopefully fixed with release 0.2.1, which is after your post. Can you please try again with the latest release and let me know if the issue persists?

Thanks

from mongodb-kubernetes-operator.

Hi @bznein

I just happened to give the operator a try today and observed the same behavior via the 0.2.0 operator version. I updated the operator to 0.2.1 and it appears to still exhibit the following event when creating the first pod

error while running "VolumeBinding" filter plugin for pod "example-openshift-mongodb-0": pod has unbound immediate PersistentVolumeClaims

I did add the following to the custom resource replica set and it appears it mapped the bound volume to the pod.

volumeClaimTemplates:
        - metadata:
            name: mongo-persistent-storage
          spec:
            storageClassName: "fast"
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 100Gi

Looking at the pod yaml, I can see the volume is properly specified that was created using the defined storage class above. Lastly, looking at the data-volume-example-openshift-mongodb-0 PVC, it does not have a PV for the PVC to operate on. It appears to want to mount a file system

volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: data-volume-example-openshift-mongodb-0 # This is the troublesome PVC
    - name: mongo-persistent-storage
      persistentVolumeClaim:
        claimName: mongo-persistent-storage-example-openshift-mongodb-0  # This PVC is created using my storage class

Edit: I made a mistake in the name of the troublesome PVC. Also, I could not find any meaningful logs related to this issue coming from the operator pod.

from mongodb-kubernetes-operator.

@chatton @bznein In order to work around the issue, we went ahead and assigned a storage class, but it still created the failing default PVC. Finally, we tried naming our storage class defined PVC the same name as the default to override the values and it appears to work.

It appears when a volume claim template is specified, it tries to merge the volume claim templates rather than replace with our defined values. So to confirm, you are not merging the values properly for storage.

It's probably not reliable long term.

from mongodb-kubernetes-operator.

This issue is being marked stale because it has been open for 60 days with no activity. Please comment if this issue is still affecting you. If there is no change, this issue will be closed in 30 days.

from mongodb-kubernetes-operator.

This issue was closed because it became stale and did not receive further updates. If the issue is still affecting you, please re-open it, or file a fresh Issue with updated information.

from mongodb-kubernetes-operator.