The overriding of remote properties stopped to work in version 2020.0.x

Works correctly in following version, you may evaluate using this repo. - spring-boot-starter-parent, version 2.3.9.RELEASE - spring-cloud-dependencies, version Hoxton.SR10

The issue is found in following version, To reproduce you may use this repo - spring-boot-starter-parent, version 2.4.4 - spring-cloud-dependencies, version 2020.0.2

Comment From: ryanjbaxter

It could be an issue, but can you please simply the samples? There are a lot of configuration files in the repos.

Comment From: wenxinleong

I should do that indeed.

OK sample please refer to repo, KO sample please refer to repo.

The sample is now simplified to just 1 remote properties file (case1-config-server-git\src\main\resources\configs\myconfig-client-app-development.properties). You may use the endpoint localhost:1001/config to read the properties.

The only differences between these 2 repos are the version of spring-boot-starter-parent and spring-cloud-dependencies.

Comment From: mariusJar

We have the same issue... Was debugging it for two days now while trying to upgrade to Spring Boot 2.4.3 and Spring Cloud 2020.1 Is there a workaround? Besides using local properties...

Comment From: ryanjbaxter

You can use the bootstrap configuration to continue to make this work in 2020.0.x. overrideNone is only taken into account in the bootstrap configuration

https://github.com/spring-cloud/spring-cloud-commons/blob/master/spring-cloud-context/src/main/java/org/springframework/cloud/bootstrap/config/PropertySourceBootstrapConfiguration.java#L172

I have not tested this out, but I am wondering if we need to adjust the order of the ConfigServerConfigDataLoader based on the property so that the other ConfigDataLoaders take precedence.

https://github.com/spring-cloud/spring-cloud-config/blob/master/spring-cloud-config-client/src/main/java/org/springframework/cloud/config/client/ConfigServerConfigDataLoader.java#L73

@spencergibb what do you think?

Comment From: spencergibb

Unfortunately, the order does of a config data loader does not affect it's priority over local imports.

Comment From: spencergibb

Can either of you @mariusJar or @wenxinleong describe your specific use case? Changing the order is no longer in the hands of spring cloud with spring.config.import. Knowing what you're specifically trying to do would be helpful.

Comment From: mariusJar

Hey @spencergibb for us the use case are quite simple. The flow:

  • Eureka Registry starts.
  • Config Server pulls configuration from git repo.
  • Config Server is started and register on Eureka.
  • Spring Cloud Gateway service is to be started next.
  • Spring Cloud Gateway has basic bootstraping config in application.yml eureka config, spring, server etc. (as boostrap.yml is deprecated in Spring Boot 2.4.X)
  • Spring Cloud Gateway uses discovery first config, similar to this:
spring:
  application:
    name: client-discovery-first
  profiles:
    active: dev
  cloud:
    config:
      fail-fast: true
      discovery:
        enabled: true
        service-id: config-server

eureka:
  client:
    enabled: true
    register-with-eureka: true
    fetch-registry: true
    serviceUrl:
      defaultZone: https://localhost:8761/eureka
  • Spring Cloud Gateway checks with Eureka where Config server is and pulls its configuration from Config Server (by profile/service-name)

And that is working fine with Spring Boot 2.1.X and Greenwich.SR4 on which we are currently running. We are trying to migrate to Spring Boot 2.4.3 and 2020.0.1 and Spring Cloud Gateway which uses spring-cloud-config-client 3.0.2 doesn't pull the remote configuration anymore. If Spring Boot is downgraded to 2.3.9.RELEASE and Hoxton.SR10 all is working as before.

(tried configuration first with direct config server url too). Any tips where the issue could be? Maybe I missed something in documentation?

Comment From: spencergibb

@mariusJar if you don't use bootstrap you need spring.config.import=configserver:

Comment From: mariusJar

@spencergibb could you share a documentation link to that maybe? Thanks!

Comment From: spencergibb

https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2020.0-Release-Notes#breaking-changes

and

https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#config-data-import

Comment From: spencergibb

waiting for a use case from @wenxinleong

Comment From: wenxinleong

@spencergibb I have a group of services that share a common template with default properties. In some service, certain properties have to be overridden.

Is good to have a default value to fallback to, this make the service behavior predictable

It also act as a reference template to make essential properties known to developers/users, where services with its own preferred properties can choose to override the value.

Comment From: ryanjbaxter

Why can't you create configuration files specific for those apps that need to override the properties?

Comment From: wenxinleong

It is possible, but there are many common properties with little need to override. What you suggest is to create multiple configuration files with a lot of duplicated properties, this will make update of common properties prone to error

Comment From: ryanjbaxter

No that is not what I am suggesting.

If you config repository has a file called application.yaml that will be included in all applications that request configuration from the config server. When you need to override properties from that file, you can create myapp.yaml and override those properties.

Comment From: wenxinleong

@ryanjbaxter I think there is some misunderstanding here? Yes, I am trying to achieve what you described. But the issue here is for some reason the local properties unable to override the remote properties (from config repository), which is why this issue is created

Comment From: ryanjbaxter

I understand the issue, and I acknowledge the problem. The problem we face is that this override behavior is out of our hands now that Boot is fetching the configuration from the config server, so there is not a simple solution to make it work from a Spring Cloud perspective.

What i am trying to determine is if its even necessary. I am just asking if you could achieve your use case using another way, ie having an application.yaml with the default properties and then create application specific properties files to override them where you need to.

Comment From: filpano

I believe what @ryanjbaxter is referring to is basically what I asked a few days ago: https://github.com/spring-cloud/spring-cloud-config/issues/1868. You might check if this would work for your use case.

Incidentally, that also answers my question.

Comment From: wenxinleong

@filpano @ryanjbaxter I'm not aware of the feature mentioned in #1868, that will address my concern instead of using override. I'll close the issue now until someone found a use case in the future.

Comment From: avnerstr

@ryanjbaxter the solution of using application.yml for the shared configuration can work if you have one repository but lets assume I have repository for each team. team A - has it's configuration in repo1 team B- has it's configuration in repo1
on each repo I have application.yml that can be shared between the team services but what if I want to have configuration that is shared for all teams, but I do want to have the ability to overide it in case it's needed.

The overide property was used to be good solution, but now since it can't be override, it can supply a full solution Any idea how I can provide this ability ?