I am able to work with cloud config server and it's working fine but I would like to know some more info. Let us assume a scenario -
- Cloud config server is getting the values using git or some database.
- My microservices are deployed on some different system which is not able to connect to config server due to network issue or something else. For the first time let us assume it got connected and getting the values. Now services are not able to connect to cloud config server but microservices are working as it didn't restart.
- Now due to some reason, we would like to restart our microservices but config server it's not up. In that case, our application won't restart.
For keeping above scenario in mind, I would like to know do we have some extension or control on config server or config client so that when config server is getting down it should take the values from local DB so that my application will keep on running. Later once the config server gets up, the Application will take the configuration from cloud config server only.
Comment From: spencergibb
No. Our current mitigation to this issue is for clients to retry and eventually fail if they can't connect.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
Comment From: manojsingh3889
Is there a possibility to open this ticket again? We are in a similar scenario, where we want to use spring cloud config as an optional mechanism to update config in real-time but doesn't want to make spring cloud config a single point of failure during deployments.
It would be nice if there is a way to use local application configuration as a fallback in the absence of spring cloud config.
Comment From: spencergibb
No, I don't think so. At that point having a config server at all doesn't make any sense. You've coupled the local service to the environment repository type (ie jdbc). At that point your service would have all the information to use embedded config server https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#_embedding_the_config_server
Comment From: mnie0508
I think the original request is quite reasonable. Embedding a config server within every service or component solely for a fallback feature introduces unnecessary complexity and overengineering. Config server downtime is, after all, an edge case rather than the norm, making such an approach disproportionate to the problem it aims to solve. A more pragmatic approach with a simple fallback mechanism could achieve the same goal more efficiently. For instance, a simple listener interface to load backed-up properties (e.g., from local files or cached configurations) would allow services to remain decoupled from the primary repository type while avoiding embedding a full config server in each service. Could this request be reconsidered?
Comment From: spencergibb
No, I don't think so. The complexity of us maintaining a local jdbc client is not worth the effort.
Comment From: spencergibb
You can already configure local properties that would be the fallback if config server is optional
Comment From: mnie0508
I am not suggesting you maintain any logic for loading the fallback properties directly. Instead, I am proposing an OnRemoteError callback or event that allows the services or projects to handle error management themselves. This approach would be a minor augmentation, providing flexibility for services to define their own fallback behavior
Comment From: spencergibb
Feel free to open a new issue