Unable to reconcile if CR contains the same extra file ConfigMap or Secret with different keys

[jianrongzhang89]

Currently, mounting extra files with a configmap or secret is done by providing a key. However, for a given configmap or secret, only one key can be used. The following configuration will fail because the configmap or secret name is used as the mount name so the same configmap or secret can not be used for multiple keys. This issue is to extend the operator to support such configuration.

    extraFiles:
      mountPath: /tmp/my-extra-files
      configMaps:
        - name: "my-backstage-extra-files-cm1"
           key: cm-file1.txt
        - name: "my-backstage-extra-files-cm1"
           key: cm-file2.txt
      secrets:
        - name: "my-backstage-extra-files-secret1"
          key: secret_file1.txt
        - name: "my-backstage-extra-files-secret1"
          key: secret_file2.txt

[gazarenkov]

Not sure I understand what exactly proposed but it seems it is covered by #179

As stated in 179, we likely should NOT require Key and mount with SubPath at all.
Please specify if you have something else in mind

[rm3l]

Yes, I think #179 would solve this if ConfigMaps/Secrets are mounted as a whole. We would just need to handle the case where two different extra-files Resources have the same name, e.g. my-extra-file ConfigMap and my-extra-file Secret both being mounted as extra files.

Meanwhile, I guess this can be reported as a bug as it prevents creating the Backstage instance correctly. This is especially annoying because, since #153 (and #160), we allow mounting extra-file Secrets by key only.

The operator fails with the following error:

2024-02-26T23:18:54+01:00       DEBUG   starting reconciliation (namespace: "my-ns/bs-app-config")      {"controller": "backstage", "controllerGroup": "rhdh.redhat.com", "controllerKind": "Ba
ckstage", "Backstage": {"name":"bs-app-config","namespace":"my-ns"}, "namespace": "my-ns", "name": "bs-app-config", "reconcileID": "a79eb636-9e70-46f8-b81f-f13e04cf5e2a"}
2024-02-26T23:18:55+01:00       ERROR   Reconciler error        {"controller": "backstage", "controllerGroup": "rhdh.redhat.com", "controllerKind": "Backstage", "Backstage": {"name":"bs-app-c
onfig","namespace":"my-ns"}, "namespace": "my-ns", "name": "bs-app-config", "reconcileID": "a79eb636-9e70-46f8-b81f-f13e04cf5e2a", "error": "failed to deploy Backstage Deployment: Deployment.
apps \"backstage-bs-app-config\" is invalid: spec.template.spec.volumes[8].name: Duplicate value: \"my-backstage-extra-files-secret1\""}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
        /home/asoro/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:324
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
        /home/asoro/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:265
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
        /home/asoro/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:226

/kind bug
/retitle Unable to reconcile if CR contains the same extra file ConfigMap or Secret with different keys.

Workaround for the user is to specify one extra file ConfigMap or Secret for each key.

[gazarenkov]

I think a configuration like this:

configMaps:
        - name: "my-backstage-extra-files-cm1"
           key: cm-file1.txt
        - name: "my-backstage-extra-files-cm1"
           key: cm-file2.txt

is rather confusing. In general, I can not get why one need to create a CM/Secret with unused keys?
I doubt it has big practical value and it can be simply workarounded creating 2 single keys CMs instead like:

configMaps:
        - name: "my-backstage-extra-file1"
        - name: "my-backstage-extra-file2"

But if we REALLY need support it I'd prefer something like:

configMaps:
        - name: "my-backstage-extra-files-cm"
           keys: 
            - name: cm-file1.txt
            - name: cm-file2.txt           

[gazarenkov]

I think ability to support one or all keys (we have now) is enough, picking several looks like overkill.