Repository navigation
Optionally force update of git repositories #2249
Description
Activity
Correct it just sends a notification to the client that its configuration has changed, it does not tell the server.
I am not sure I like option 2 where the client can override the server behavior. That would mean anyone could make a request to the server causing it to make a request to the git server.
You make a good point that it would be great if there was a webhook for the server, so the server knows a git repo it is using has changed and it could expire the refresh rate.
I've just spent a couple hours debugging and troubleshooting the config server as it wasn't refreshing the server-side git repository, upon receiving a WebHook request from GitLab.
What's the use case of the
/monitorendpoint, considering the official docs explicitly mention SCM WebHooks as an example, when there's no chance that config clients are ever able to obtain the latest SCM-hosted configuration?I'm willing to help implement a solution as this is a feature that I would really like to have. As far as I can tell, there are likely two things that need to be tackled:
- The config monitor needs a way to tell the config server to reload the configured
EnvironmentRepositoryinstances and wait for their feedback, before dispatching any refresh events to the Cloud Bus. - The currently present
EnvironmentRepositoryimplementations would have to be extended to support refreshing, even when their regular timed refresh interval hasn't expired yet.
Would this be a strategy that you'd be aligned with, or would you recommend another approach?
- The config monitor needs a way to tell the config server to reload the configured
I've just spent a couple hours debugging and troubleshooting the config server as it wasn't refreshing the server-side git repository, upon receiving a WebHook request from GitLab.
That is not the intended use case. The WebHook from GitLab notifies the config server of a configuration change. Based on the what configuration file(s) changed the config server will then post an event to any applications that may be impacted. When the applications recieve the remote event it triggers them to refresh their application context which in turn causes a request back to the config server for the application's configuration. This in turn would cause the the config server to fetch the configuration from the environment repository (GitLab in your case).
Now in the case of Git there is a refresh interval property that could be set and in theory if that interval has not passed the config server may not do a pull on the remote Git repo and therefore not return the newest configuration to the client. That was the issue the OP was reporting I believe.
I picked this up following the direction you suggested: the config server expires its own refresh rate when it learns that a repository changed. PR: #3342.
When
/monitorreceives a notification that affects at least one application,PropertyPathEndpointnow calls a newJGitEnvironmentRepository#expireRefreshRate()on the server's Git repositories before notifying the applications.MultipleJGitEnvironmentRepositoryalso expires the repositories it manages, including the placeholder ones. The next request fetches from the remote, so the refreshed applications get the commit that triggered the webhook. Notifications whose paths are all ignored don't expire anything.On the concern about anyone being able to make the server hit the Git server: this doesn't add a new trigger. It only lets the refresh that
/monitoralready causes actually fetch, at most once per notification, and the existing webhook validators still apply. A negative refresh rate (never fetch) is unchanged.
Is your feature request related to a problem? Please describe.
I want to use the refreshRate property for 2 reasons:
Unfortunately, there are also scenario's where you need an immediate refresh. Specifically, we have cicd pipelines that push a new tag to the config repo, and right after that a pod is spun up which will try to fetch that specific config.
Describe the solution you'd like
Possible solutions:
?force-update=true, spring-cloud-config-server should always.Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
refreshRatesetting at all; wouldn't the client then on refresh still potentially get the old config?