Environment is being used rather than active profiles for config server

[thompson-tomo]

This issue is to look into using profiles as suggested by @TimHess in the below comment.

          Steeltoe supports multiple labels, but stops at the first one it finds since you probably don't want to config values from multiple branches. I suspect you want to use `profiles` rather than labels

Originally posted by @TimHess in #1284 (comment)

What i am wanting to achieve is the grouping of config based on what they achieve for instance a Eureka Profile, a client application should only use the profiles which are active as defined under: https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#_environment_repository

However when looking at the code, currently there is only 1 location where in which profiles are referenced which are in the return object:

Steeltoe/src/Configuration/src/ConfigServerBase/ConfigServerConfigurationProvider.cs

Line 339 in 8ae9892

"Located environment name: {name}, profiles: {profiles}, labels: {label}, version: {version}, state: {state}", env.Name, env.Profiles, env.Label, env.Version, env.State);

which is probably ok if we are to assume the server does the filtering which i believe should be the case.

Looking at the properties which populates the config server url, it appears that the profile is coded to be the Environment as defined in settings which I don't feel is correct as the active should be defined separately.

Steeltoe/src/Configuration/src/ConfigServerBase/ConfigServerConfigurationProvider.cs

Line 727 in 8ae9892

var path = $"{_settings.Name}/{_settings.Environment}";

I also feel that if no active profiles are defined the profile "Default" be more accurate as mentioned in (https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#config-data-import)?

At the same time the environment Endpoint is not reading the active profiles from config but instead is always returning just the Environment name as the profile.

Steeltoe/src/Management/src/EndpointBase/Env/EnvEndpoint.cs

Line 47 in 8ae9892

IList<string> activeProfiles = new List<string>() { _env.EnvironmentName };

My expectation would be that a user can define the active profiles as described in the above link, and those values are returned from the server using the environment endpoint and at the same time it is used to ensure only the relevant config is fetched from the server.

Note have created #1295 to handle the step process.

[TimHess]

I believe Steeltoe's Config Server client was created with the viewpoint that ASPNETCORE_ENVIRONMENT was effectively equivalent to profiles, though lacking support for multiple active values. I suspect that proper support for multiple active profiles would be larger than we can stuff inside a config provider, but that would probably also be required to make the env endpoint work the way you are expecting (since it is also bound by the IConfiguration family of interfaces and has no dependency on our config server client)

Multiple active profiles is an interesting idea that I would not permanently rule out, but we are not likely to make progress on it in the next few months. Changing the default value to Default could put us a bit at odds with using ASPNETCORE_ENVIRONMENT if we don't do it right.

In the absence of the exact functionality you're after, is it workable to use the Environment setting to get the config profiles you need?

[thompson-tomo]

Hmm,I suspect I would run in to a couple of issues due to the fact I am running multiple micro services on the same VM with potential different profiles needed.

What I see as the options would be:

• Due to me using a custom config server endpoint I could define my profiles on the server & then use that to build the necessary config properties. Note a nice solution.
• contributing to steeltoe the necessary changes in stages
• • in v4 branch change default profile to "Default,{{Environment}}" due to it being viewed as a breaking change
• • read active profiles from config and replace the default in request (use this issue)
• • implementation of the 2 step process (use issue 2 step import not happening #1295) - v4 branch only
• • adjust the environment endpoint (create new issue)

I suspect for me it would be more beneficial/easier to tackle this at the root rather than try and work around it.

If you support this idea I can work through this.

Note I am currently at cross roads with my project hence why I have spent so much time on it over the weekends with the key thing being ensuring I am able to obtain easily obtain all the necessary config without implementing to many workarounds.