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 EnvironmentRepository
s 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 someEnvironmentRepository
s 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...