Persistent Volume support for Operator Deployment Pod

[vivekr-splunk]

Feature Request

Is your feature request related to a problem? Please describe.
Hello, We are working on splunk operator. version 2.0.0 of splunk operator requires persistent volume to be mounted to splunk operator deployment. but bundle creation using olm do not allow persistent volume creation. How can I support in persistent volume when we use bundle deployment.

Describe the solution you'd like
support for persistent volume in bundle for operator pod deployment

[dmesser]

Hi @vivekr-splunk

https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/subscription-config.md#volumemounts exists to augment a deployed operators with mounting an existing volume, but it doesn't seem that's quite what you are after.

Can you comment on the use case where a Kubernetes controllers needs a persistent volume mount?

[squakez]

I have the same need. The volumeMounts works if the PVC was previously created. The requirements would be to create the PVC on the fly, right before creating the Deployment, for instance by specifying the StorageClass (or fallback to use the one marked as default if none is provided). Trying to define how the yaml could look like with the presence of a volumes parameter:

spec:
  apiservicedefinitions: {}
  customresourcedefinitions:
    ...
  install:
    spec:
      clusterPermissions:
     ...
      volumes:
      - camel-k-pvc:
          accessModes:
              - ReadWriteOnce
              resources:
                requests:
                  storage: 20Gi
              storageClassName: standard
      deployments:
      - name: camel-k-operator
        spec:
          ...
              serviceAccountName: camel-k-operator
              volumes:
              - name: camel-k-pvc
                persistentVolumeClaim:
                  claimName: camel-k-pvc

Without this feature, we are in the situation to ask the user to create such a PVC before running the installation procedure, which is a bit against the idea of letting everything managed by the subscription.

[squakez]

@vivekr-splunk given you opened this sometime ago, have you managed to find some workaround by any chance?