Problem Description We use EKS for deployments and our Spring active profile is used for deployment environment definition However composite config for config service requires composite profile to be activated

spring:
  application:
    name: config-service
  profiles:
    active: composite
  cloud:
    config:
      server:
        composite:
          -
            type: git
            uri: <your_repo_url>
          -
            type: awss3
            bucket: <your_bucket>

if composite profile is not set, it doesn't work. The same is related to any other config sources apart from git.

For example, if I want awss3 bucket to work, I must set active awss3 profile Example:

spring:
  application:
    name: config-service
  profiles:
    active: awss3
  cloud:
    config:
      server:
        awss3:
          bucket: <your_bucket>

if awss3 was not set to be active, the config would not take an effect

Suggested solution Allow usage spring profiles like in any other Spring Boot projects, without specific profiles

Example:

spring:
  application:
    name: config-service
  profiles:
    active: dev
---
spring:
  config:
    activate:
      on-profile: dev
  cloud:
    config:
      server:
        composite:
          -
            type: git
            uri: <your_repo_url>
          -
            type: awss3
            bucket: <your_bucket>

In the example above I would expect the composite setup would be active, but it is not.

or in the following config, I would expect in dev profile aws s3 backend would be active and in qa profile it will use git as a backend

spring:
  application:
    name: config-service
  profiles:
    active: dev
---
spring:
  config:
    activate:
      on-profile: dev
  cloud:
    config:
      server:
        awss3:
          bucket: <your_bucket>
---
spring:
  config:
    activate:
      on-profile: qa
  cloud:
    config:
      server:
        git:
          uri: <your_repo_url>

But this approach doesn't work.

We have 30+ Spring Boot services following a naming convention where the active profile is = to env name Where Config Service forces to use their own hardcoded profile names instead of the common pattern of Spring Boot profiles usage.

I know that active profiles can be combined through a comma, but in our case, it is not required and only Config Service require this, which feels incorrect approach.

Comment From: ryanjbaxter

Why not separate the configurations out into their own docs?
application-dev.yaml contains

spring:
  profiles:
    active: awss3
  cloud:
    config:
      server:
        awss3:
          bucket: <your_bucket>

application-qa.yaml contains

spring:
  profiles:
    active: git
  cloud:
    config:
      server:
        git:
          uri: <your_repo_url>

Comment From: Bryksin

The problem here is not in the file separation or how to solve the problem, having several profiles through commas is also a solution. Workarounds exist and they are not so problematic.

However, this ticket is about hardcoded obligatory profile names that must be used to activate different backends support which feels a bit incorrect. Developers should be able to use any profile names they want, and it should not affect the functionality. If the config file contains configuration for AWS s3 it should be enabled without a specific profile name like awss3 or composite or else...

Comment From: ryanjbaxter

So you are basically just suggesting we remove the requirement for profiles and just use the presence of specific properties to dictate functionality?

I think someone could make a similar argument in the other direction as well. They may like the fact that things don't take effect unless specific profiles are enabled.

I am not sure there is an approach that please everyone.

Comment From: Bryksin

Well, I was taking for reference the standard spring boot application, non of the integrations required a specific active profile. As I mentioned we have 30+ microservices tidily integrated with AWS and EKS and non-of them require awss3 active profile to start working with S3 bucket :)

These hardcoded profiles names just caught my eye because they are definitely standing out from standard spring boot profiles usage and it is just not logical from the config file point of view, have a look at this example:

spring:
  application:
    name: config-service
  profiles:
    active: dev
---
spring:
  config:
    activate:
      on-profile: dev
  cloud:
    config:
      server:
        composite:
          -
            type: git
            uri: <your_repo_url>
          -
            type: awss3
            bucket: <your_bucket>

How is that hinting to me that I should use a composite profile? it just doesn't make sense. As a developer, I would expect that if dev profile is active, the rest of the config under that profile will be active, as it does for any spring boot app, but in case of config service it doesn't, I need to search documentation and find out that apparently profile names (per each backend integration) are hardcoded and if I want them to work I must active them separately or by using composite

Comment From: ryanjbaxter

This has been this way for a while, would love to now if others have similar thoughts as you