This issue has been addressed here How do I setup a local fallback config for Spring Cloud Config service incase remote repo is not available? . However the solution seems to be very manual.

I would have hoped that by using order I could; order:1 try git and if it is accessible, clone/pull to baseDir. If GIT access fails use order:2 native to access git:baseDir via native:seachLocations.

I would have thought, it would be better for order:1 to not delete baseDir before attempting GIT and only if GIT is available proceed with re-building baseDir.

As the linked solution suggests, in order to get around this problem, I need to start config with 'clone/pull' set, then remove, before the next run.

I see this issue mentioned in a number of places e.g. [#631] (https://github.com/spring-cloud/spring-cloud-config/issues/631) - however this issue and others seems to all point to each other and I don't see a resolution.

Comment From: ryanjbaxter

Just to be clear the fallback between git and native using a composite configuration works, but the problem is that trying to git configuration first will delete the directory if it exists and then if it fails the native "fallback" won't work, is that correct?

Comment From: lafual

Yes, you understood correctly. Admittedly I tried it on Hoxton.SR3. I haven't retried yet on the latest build.

This issue would only be a problem if I started Config Server while GIT was inaccessible. In our organisation, our GIT server is not regarded as part of production infrastructure and therefore shouldn't be a basis of a production cloud system. Therefore we are only using “native” and doing a “git pull” when changes are necessary.

Comment From: ryanjbaxter

I haven't looked at the code, but my guess is the reason it behaves this way is because we only know the git server is unavailable if the clone fails, so we need to delete the directory preemptively in order to make sure the clone can succeed assuming the git server is available.

One option would be to move the basedir to a temp directory if it exists, then clone the repo, and if an exception is thrown restore the basedir allowing a native fallback to work.

Comment From: lafual

Your solution seems reasonable. However, on reading further, I am not sure if the order attribute is intended as a fail-over. From the reference manual "Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment".

Therefore the proposal in https://github.com/spring-cloud/spring-cloud-config/issues/1702 seems more appropriate (i.e. a new parameter vs re-purposing order) .

My question is a repeat of https://github.com/spring-cloud/spring-cloud-config/issues/617 , https://github.com/spring-cloud/spring-cloud-config/issues/1702 and https://github.com/spring-cloud/spring-cloud-config/pull/1220 . Each of these posts seems to refer to the other as resolving, but none seem to resolve the issue in hand.

Comment From: ryanjbaxter

"Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment".

We need to remove that note, its not true anymore, that was addressed in this issue https://github.com/spring-cloud/spring-cloud-config/issues/661.

You need to set spring.cloud.config.server.failOnCompositeError to false, by default it is true.

617 is still open, meaning its not resolved. However, @spencergibb's comment on that issue (https://github.com/spring-cloud/spring-cloud-config/issues/617#issuecomment-275436934) is exactly what you are trying to do, use a composite. I don't think using a composite with order is a bad way of implementing what you are trying to do.

Comment From: marbon87

The problem with spring.cloud.config.server.failOnCompositeError=false is that you don't get any failure on the health-endpoint, showing that the main repository is not available. Furthermore if all repositories are not accessible, the health endpoint is still up.

Comment From: ryanjbaxter

@marbon87 if that is true, that is a separate issue(s)

Comment From: amitmalul7

Joining for the thread with the same concern, we're looking for a fallback solution in case where the git repository is unavailable. Moving the basedir to a temp directory if it exists, then clone the repo and throwing an exception will do the job. @ryanjbaxter However, this fallback scenario is raising a question, what is the frequency the local repo atbaseDir being updated? can we control it? I've noticed calling to /actuator/health do the job, can we rely on that?

Comment From: ryanjbaxter

I dont think anything calling /actuator/health would update the local repo because it would not be a git repo at that point

Comment From: amitmalul7

@ryanjbaxter yeah that makes sense, my question was whether in general there is an option to control the frequency of updating the local repo?

Comment From: ryanjbaxter

I'm not following because the local repo is not a git repo, so how is it being updated? And from where?

Comment From: amitmalul7

By mentioning "local repo" I meant the configuration files that cloned from the remote GitHub repo to baseDir. Let's say I configured a config server with GitHub as the only backend, and I've set baseDirto a certain path on the server. When the config server got restart, I see it's pull/clone from GitHub and pulled the updated configuration from the remote repo to local configuration files at baseDir. Other than when the server restart, are there further scenarios when the config server pulled / cloned from GIT remote repo to the local configuration files at baseDir?

The agenda is to keep the local configuration at baseDir synced with the remote repo so in case of GIT outage to have updated configuration files. I hope I clear my point.

Comment From: ryanjbaxter

Got you. Yes whenever there is a request for configuration from the config server it will do a pull from the git repo. There is a refresh rate setting that would impact this though https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#_git_refresh_rate

Comment From: vertex-github

Why do we have to delete the baseDir everytime? Couldn't we check on startup that the dir is either empty or is a valid git repo and then simply fail on startup if that's not the case? Wouldn't subsequent pulls (or a clone if dir is empty) using git tools take care of the updates for all subsequent requests? E.g. i don't delete my local git repos everytime i want to get the latest mainline code - why should we delete here?

Comment From: ryanjbaxter

I don't think we have to but that is just the current behavior