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 ConfigDataLoader
s 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 ?