Profiles Not Tied To Application

[jeffjohnston]

We have been using the config server for a few months now and really like it. However, we would like to be able to declare global properties that are not tied to a given application and then reference them using profiles. The reason is we have a lot of properties that are copy and pasted between micro-services and would like to move them up to a global level based on a named profile.

The documentation shows that everything is tied to an application.

The HTTP service has resources in the form:

/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties

We would like to add:

The HTTP service has resources in the form:

...
/{profile}.yml

As an example we have multiple micro-services that make soap calls to an SAP backend and they will only ever have 3 configurations (dev,test,prod). We would like to be able to name these sap-dev.yml, sap-tst.yml, and sap-prd.yml, which of course would be the name of a profile. These would not be tied to any given application name.

We are coming from a monolith application and trying to split things out, but it still feels like there would be some overlap between resources that you need to run applications with even if we were just starting out fresh.

We are not using a git to pull the properties.

[spencergibb]

Why not application-sapdev.yml?

[dsyer]

Kind of a duplicate of #286. I think I prefer to keep the endpoints as they are though and deal with the "global" properties in the internals. Having said that, there are already features that support global properties: any "application_._" resources that are not part of the config server configuration are treated as global (in the default repo for git repositories or in the root of the base directory for a native one). (What @spencergibb said in other words.)

We are not using a git to pull the properties.

Why? I'm sure you have reasons, but they are probably worth re-evaluating, given the extra level of support you get from git being the primary backend.

[jeffjohnston]

But that is the crux of the problem. We have 2 spring boot applications that have names web and shop that both need access to SAP. By being tied at the application scope we have to copy and paste the configuration because the most global we can get is web-sapdev.yml and shop-sapdev.yml. Both files would still be the same.

We dug into the code and think we know where everything is tied to the application (name). Just wondering if there would be any chance to make this more optional.

Why? I'm sure you have reasons, but they are probably worth re-evaluating, given the extra level of support you get from git being the primary backend.

Still wading into the waters of cloud. We will be looking at this more in the future. I only mentioned it so you would know my setup.

[spencergibb]

Maybe there is some misunderstanding, application-sapdev.yml will be applied to all applications with the sapdev profile.

[jeffjohnston]

Perfect! Exactly what we were looking for. I did not gather that from the docs. Thank you!