smallrye-config icon indicating copy to clipboard operation
smallrye-config copied to clipboard

feature: Support intermediate config directories in FileSystemConfigSource like /configs.d/*/

Open vladimirfx opened this issue 4 years ago • 1 comments

In process of migrating some Spring Boot projects to Quarkus, we discover a lack of this feature. Our current Pod config looks like this:

          env:
            - name: SPRING_CONFIG_ADDITIONAL_LOCATION
              value: optional:configtree:/config.d/*/

At deployment time Ops team projects secrets like that:

          volumeMounts:
            - name: activemq-config
              mountPath: /config/activemq
              readOnly: true
            - name: smtp-config
              mountPath: /config.d/smpt
              readOnly: true
            - name: database-config
              mountPath: /config.d/database
              readOnly: true

In different environments, the exact number and target of such volume mounts may differ (ex. SMTP config set by main app config in DEV).

It would be nice if this work in Quarkus:

          env:
            - name: SMALLRYE_CONFIG_SOURCE_FILE_LOCATIONS
              value: /config.d/*/

if you are OK with that feature I can provide a PR.

vladimirfx avatar Dec 25 '21 07:12 vladimirfx

Hi @vladimirfx

Sure. Feel free to provide a PR. Thanks :)

radcortez avatar Jan 03 '22 11:01 radcortez

I am closing this due to the lack of activity.

radcortez avatar Jul 05 '23 22:07 radcortez

Perhaps a better approach (for UX at least) to solving the same problem would be (for each config source which deals with the filesystem) to recognize whether the target file name is a directory, and if so, read the directory contents in this manner (sorted order, concatenated). I don't recall if the current code is currently set up to easily do this though.

dmlloyd avatar Jul 06 '23 18:07 dmlloyd

We added support to read the entire content of a directory for most sources, but it is limited to a single level. I believe the request was to support recursive listing (or at least one more level).

Do you think this is something we should pursue?

radcortez avatar Jul 06 '23 23:07 radcortez

It's probably not worth going farther then at this time.

dmlloyd avatar Jul 08 '23 00:07 dmlloyd