At a workshop with @mstine a few questions came up about how to deal with internal git repository maintenance windows and outages. One of the potential resolutions was to modify the SCC server to accept a secondary git repository in the event that the first repository is unavailable, ala Hystrix fallbacks.

Perhaps something along the lines of spring.cloud.config.server.git.fallbackUris=host1,host2

Any thoughts on usefulness/if it would be worth the additional complexity?

Comment From: spencergibb

There is currently a composite EnvironmentRepository. You could list both. Currently, if git on host1 failed the whole request would fail. We could add an option to keep going even if some EnvironmentRepositorys fail.

Comment From: cah-andrew-fitzgerald

Would it make sense to open an additional issue for allowing the config server to serve stale data in the event that it has done an initial pull from the git repo, but is unable to connect and refresh?

Comment From: spencergibb

There are [various] cache related issues, if one of them fits, comment there.

Comment From: sarveshkaushal

This would be a nice enhancement if connection to git fails, configurations are picked from local file on config-server.

Comment From: karl-ravn

@cah-andrewfitzgerald: PR https://github.com/spring-cloud/spring-cloud-config/pull/749 could potentially work for you in the case of serving stale data. It also offloads the git server in case there are lots of servers refreshing their configuration regularly. There is the potential to improve on my PR to force updates from the outside (scheduled task), but not without breaking the current interfaces.

Comment From: Torbilicious

This would be really nice. We currently have problems with bitbucket and needed to deploy an emergency update using another hoster...

Comment From: matzegebbe

same problem here

Comment From: GuiF007

There is currently a composite EnvironmentRepository. You could list both. Currently, if git on host1 failed the whole request would fail. We could add an option to keep going even if some EnvironmentRepositorys fail.

Is this on the way ? As I understand, we can go around this "backup" problem using a custom EnvironmentRepository but not that great.

We had a case for some reason the on-premise-Gitlab is down... So none of our microservices can be started without Gitlab :/

Comment From: ikhangt

@GuiF007 I have a very similar concern. Did you come up with a workaround?

Comment From: GuiF007

@ikhangt As it was with Openshift, we created a volume with the configuration inside. This volume is automatically updated everytime a configuration is asked. And it does not crash if the repo is not available, taking the last config retrieved...