-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Common properties shared to all clients with multiple git config server #286
Comments
Could escaping the placeholders be an option? When I try it like this: overrides:
eureka.instance.statusPageUrlPath: $\\{server.contextPath}/info
eureka.instance.healthCheckUrlPath: $\\{server.contextPath}/health
info.configuration.uri: $\\{spring.cloud.config.uri} The resulting json exposed on the endpoint looks like this: "propertySources": [
{
"name": "overrides",
"source": {
"info.configuration.uri": "$\\\\{spring.cloud.config.uri}",
"eureka.instance.statusPageUrlPath": "$\\\\{server.contextPath}/info",
"eureka.instance.healthCheckUrlPath": "$\\\\{server.contextPath}/health"
}
} Is this supposed to be like this? |
I don't think you need to escape the "" in YAML. So Overrides aren't really a great solution if you want to change the properties locally in the apps. If it works for you for now that's great though. |
That did the trick! Thanks! Overrides are indeed a solution we wouldn't use if there was another way to do this. |
@andreasevers I think I submitted a similar request at #383...
This is a requirement we need to get done, since we have multiple teams reusing a global configuration that is shared across all teams... But each of them should have control on their own repos... thanks |
I'll look into it tomorrow @marcellodesales , stay tuned :) |
@andreasevers 👍 Let me know of any development... |
@andreasevers Any news❔ |
Sorry for the radio silence @marcellodesales , had a very busy week. I love your structured explanation in #383 , and I agree it's overlapping with this issue. This would mean the eventual solution would have the following effect on any given application with a profile active:
1 being top priority and 5 being lowest priority I also believe global properties should come from a separate repository. Right now the overrides are defined in the config server itself, which means to change them we need to change the properties, build the config server, release it and deploy it (unless we externalize it but it would be a shame not to use git for this). It would be great to have the possibility to define properties that can be overwritten by the application repositories, but also to define properties that will overwrite any property found in application repositories (like the current @dsyer does that sound reasonable? If so, maybe me and @marcellodesales can work together on a PR. |
Some of that makes sense. What I can't get straight in my head (and why I haven't done this myself) is that as soon as you have 2 repositories contributing to the same configuration |
@andreasevers Thanks for your notes as well... So far I'm in need of @dsyer I'm looking in the same angle: global repos would be missing labels, but we could default to The intent is that this global repo can serve the global properties in all levels:
Since the core team communicates with the capability teams, we can always start with the defaults as usual. The resolution for requests of inexistent labels would resolve in loading the default `master. This could also be an option provided in the bootstrap.yml. |
I don't think you want the global repos to not use labels. As an example, say you use labels for environments DEV and PROD and your global configuration is for a common service like RabbitMQ. You'd still want the global config to load the DEV rabbit uri in the DEV environment and the PROD rabbit uri in the PROD environment. Personally, I'd rather the "global" area of the config be assumed to only hold "application.yml" or "application.properties" files but I don't see why you could also allow application-specific configuration files there. I'd expect the config server to pull the configuration in this order in that case (bottom config wins):
I can see how this could easily be confusing though. I think it's important to spell out exactly what happens when you include a "global" config repository. Since it would change the behavior in the presence of multiple repositories, I'd propose configuring this look like this:
This specific example is a bit non-sensical since you wouldn't want shared configuration to be stored per-application. But you might want to be able to have multiple global configurations on a per-team basis or something like that. |
Now I am also facing the same issue to keep global properties should keep in separate repository. Do we have any workaround or solution ?? @andreasevers |
Did you try using a composite repository? |
Yeah, I tried composite repository but its not working in my case, where both global properties and application properties should use different labels. |
If you could create a sample app and post a link that would be super |
Does anybody know if there is any solution for this as I have a similar problem. I have the scenario where a team manages the global-repository level configuration that includes host information, authentication keys etc and they will update this as these properties change. These are common to most services. So basically this repository will contain We then have a service-repository that has the specific service level properties. This contains the Let's say that I have a service named |
so far just the composite. |
Hey,
We have a quite complex setup of our configuration server. We have one repository per microservice to be able to manage access rights separately for each microservice.
We would like to _share configuration_ to all clients. We used to be able to do this using the
native
profile (as described here), but with changing to git as configuration storage, we seem to have lost that option.I have tried using a combination of native and git, but that is not supported.
Next I tried to use the
spring.cloud.config.server.git.uri
property as a common repo, but that only acts as a fallback ifspring.cloud.config.server.git.repos.*
are not successfully matching configuration for a specific call to the config server.My last option seemed using
spring.cloud.config.server.git.overrides
, which was working great, until I wanted to use variables such as this:Note: There seems to have been a lot of refactors in the
org.springframework.cloud.config.server
package, so I'm not sure theoverrides
property is still there.The config server already fills in the variables before exposing them as json on the REST endpoints.
The result is that all clients receive the following:
So long story short, we are stuck. Either we continue to use the overrides configuration, and find a solution to passing the variables without being filled in by the config server itself, or we have to find another solution which allows us to share configuration to all clients while using a repository per microservice.
Cheers,
Andreas
The text was updated successfully, but these errors were encountered: