New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuration of a backup git repository #617

cah-andrewfitzgerald opened this Issue Jan 26, 2017 · 6 comments


None yet
6 participants

cah-andrewfitzgerald commented Jan 26, 2017

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,host2

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


This comment has been minimized.


spencergibb commented Jan 26, 2017

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.

@ryanjbaxter ryanjbaxter self-assigned this Jan 26, 2017


This comment has been minimized.

cah-andrewfitzgerald commented Feb 1, 2017

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?


This comment has been minimized.


spencergibb commented Feb 1, 2017

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


This comment has been minimized.

sarveshkaushal commented Apr 26, 2017

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


This comment has been minimized.


karl-ravn commented Jul 26, 2017

@cah-andrewfitzgerald: PR #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.


This comment has been minimized.

Torbilicious commented Jan 9, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment