configMap for default.d directory about cvmfs-csi

[jtorrex]

Tried to add a custom configMap for define default.d files editing:

deployments/helm/cvmfs-csi/templates/_helpers.tpl

{{- define "cvmfs-csi.cm.default.d" -}}
{{ (index .Values.cvmfsConfig "default.d" "configMapName") | default (printf "%s-default-d" (include "cvmfs-csi.fullname" .)) }}
{{- end -}}

deployments/helm/cvmfs-csi/templates/cvmfs-config-configmap.yaml

{{- if (index .Values.cvmfsConfig "default.d" "create") }}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "cvmfs-csi.cm.default.d" . }}
  labels:
    {{- include "cvmfs-csi.common.metaLabels" .  | nindent 4 }}
data:
  {{- range $path, $data := (index .Values.cvmfsConfig "default.d" "data") -}}
  {{- $path | nindent 2 }}: |
    {{- tpl $data $ | nindent 4 -}}
  {{- end }}
{{- end }}

deployments/helm/cvmfs-csi/templates/nodeplugin-daemonset.yaml

 {{- if (index .Values.cvmfsConfig "default.d" "use") }}
            - name: cvmfs-config-default-d
              mountPath: /etc/cvmfs/default.d
            {{- end }}

deployments/helm/cvmfs-csi/values.yaml

default.d:
    configMapName: cvmfs-csi-default-d
  
    # Whether to use this ConfigMap in /etc/cvmfs/default.local.
    use: true
  
    # Whether to create default.local ConfigMap with data entries defined below.
    # If not, and `use` is set to true, it is expected the ConfigMap is already present.
    create: true
  
    data:
     90-cvmfs.conf: |
       CVMFS_CONFIG_REPOSITORY=cvmfs-config.test.com
       CVMFS_DEFAULT_DOMAIN=cvmfs.test.com

But obtaining:

 $ helm install cvmfs . -f values.yaml
Error: INSTALLATION FAILED: DaemonSet.apps "cvmfs-cvmfs-csi-nodeplugin" is invalid: spec.template.spec.containers[1].volumeMounts[8].name: Not found: "cvmfs-config-default-d"

Any clue on that?

[gman0]

Hi @jtorrex, thanks for reporting! Indeed this should be available. Would a separate volume mounted in /etc/cvmfs be ok? #54

[jtorrex]

Hi @gman0, thanks for your reply and your work.

I'm currently mapping the configuration using configMaps and I find this mechanism enough simple and intuitive to "store" the proper configuration on the values.yml file, having also the capacity to track it easily on a control version such as Git/GH/GL, etc, and using it "transparently" on integrations without involving "existent" files on storage support to mount it later.

About the proposal on issue #54, If I can decide, I would probably choose to stay on configMaps but adding some others like /etc/cvmfs/defaul.d/*, for example. Anyway, I'm conscient that keeping this mechanism requires additional work on the code to add extra configMaps if required, modifying different files.

If you are considering the volume mount approach because is more flexible, please, go ahead, you probably have a better understanding of what is better to improve the usability of the plugin, the only point that I consider that is mandatory if you decide to change to this approach, is to have a good section docu/guide explaining on how to use it properly.

Thanks again for your work, if I can help you with whatever you consider, please don't hesitate on mentioning me.

Regards!

[gman0]

Hi @jtorrex, you can check #56 if that would work for you. Thanks!

[jtorrex]

Checked #56. For my particular use case, I think that we can close this issue as the new patch provides a better flexible way for mapping the desired configuration. Thanks for your work again @gman0.