All documentation I found so far regarding spring.config.import pointed to the following example:

Multiple files are written to a directory tree, with the filename becoming the ‘key’ and the contents becoming the ‘value’.
...
As an example, let’s imagine that Kubernetes has mounted the following volume:
etc/
  config/
    myapp/
      username
      password

For me it was quite hard to figure out that filenames with dot are also correctly mapped. Like when I mount a secret for spring.datasource.username and spring.datasource.password to etc/secret/properties, k8s will create

etc/secret/properties/spring.datasource.username
etc/secret/properties/spring.datasource.password

Where the doc had led me to somehow change it to this, resulting in a lot of manual mapping:

etc/secret/properties/spring/datasource/username
etc/secret/properties/spring/datasource/password

However, the dot separated files will already be mapped to the corresponding properties with spring.config.import=configtree:/etc/secrets/properties/. I think the documentation is assuming that every single secret is explicitly mapped to a subpath.

Like

- name: datasource-secret
   mountPath: /etc/deleteme/spring/datasource
   readOnly: true

with keys username & password

or even

  - name: my-secret
    secret:
      secretName: my-secret
      optional: false
      items:
        - key: spring.datasource.password
          path: "spring/datasource/password"
        - key: spring.datasource.username
          path: "spring/datasource/username"

Am I missing something here, or is it indeed only not documented? What would win if both are specified? Is it expected that secrets are supposed to be in the granularity of the properties prefix? Or that a mapping to "/" is done for every key?

Comment From: mbhave

My understanding is that the subpaths was a more common pattern in Kubernetes. We have documented that dots work but more in relation to Docker secrets:

Configuration trees can also be used for Docker secrets. When a Docker swarm service is granted access to a secret, the secret gets mounted into the container. For example, if a secret named db.password is mounted at location /run/secrets/, you can make db.password available to the Spring environment using the following:

I agree it is kind of hidden and we could make it more obvious that filenames with dots will work for config maps too.

Comment From: dvonsegg

I would like to work on this issue.

Comment From: mbhave

Closing in favor of PR #28170.