Common properties shared to all clients with multiple git config server

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 if spring.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:

overrides:
          eureka.instance.statusPageUrlPath: ${server.contextPath}/info
          eureka.instance.healthCheckUrlPath: ${server.contextPath}/health
          info.configuration.uri: ${spring.cloud.config.uri}

Note: There seems to have been a lot of refactors in the org.springframework.cloud.config.server package, so I’m not sure the overrides 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:

  "propertySources": [
    {
      "name": "overrides",
      "source": {
        "info.configuration.uri": "${spring.cloud.config.uri}",
        "eureka.instance.statusPageUrlPath": "/configuration/info",
        "eureka.instance.healthCheckUrlPath": "/configuration/health"
      }
    }

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

[spencergibb]

so far just the composite.

[dsyer]

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 Environment there’s a chance they don’t have the same labels. In fact I’d say it is necessary that individual teams can push new labels for their apps without having to change the global defaults. I think it means there is some tricky processing to do in the EnvironmentRepository, and I wouldn’t want to do that in the existing repository implementation. The best way to implement it is probably to keep the existing repository and fold it into a composite, which takes the output as it is now and prepends stuff from a default git repository (of which there is only one).