Configuring gRPC server with spring cloud config

[primoze]

Is there any way to configure the gRPC server with the spring cloud config client extension? My logs show that the server is being queried, and the config keys exist (quarkus.grpc.server.port), but the gRPC server tries to start on port 9000, which is unavailable. I tried adding my own ConfigSource implementation, and using that the gRPC server picks it up. Any reason the config server isn't being used, or is it a bug?

[quarkus-bot[bot]]

/cc @alesj (grpc), @aureamunoz (spring), @cescoffier (grpc), @edeandrea (spring), @geoand (spring), @radcortez (config)

[primoze]

Idk, it makes spring profiles pretty much useless

[radcortez]

For example, in my case it uses the port in the application.yml (or application-prod.yml, if it exists), but ignores the one in the application-staging.yml, even if the prod one doesn't exist.

If Quarkus is running in prod mode, why should the staging profile be used? What is your exact expectation?

[primoze]

Ok, maybe I wasn't clear enough (and using staging as an example was probably not the best choice). My expectation is being able to combine multiple spring profiles to get the final config. And AFAIK the quarkus prod profile is used in the final build, and has nothing to do with the environment (prod/prod-euc1/etc, non-prod/staging/ci/stress/etc) the application is actually deployed in. So I would like to use the spring config profiles for env specific configuration, as with the spring config client.

• Unless the spring cloud config profiles include prod the values from the server are ignored
• If the spring cloud config profiles include prod, but also has other profiles then those other profiles are ignored. For example: prod,euc1 ignores the euc1 profile, which is supported in springboot if there are multiple profiles, the last one wins (similar to adding entries to a Map).

Behaviour discrepancy

In fact, when examining further, I found out that the config server client does not behave the same way as the springboot one.
Invoking my app with QUARKUS_SPRING_CLOUD_CONFIG_PROFILES=aws,euc1 set the quarkus app produces the following logs on the config server:

Adding property source: Config resource 'file [/path/application-euc1.yml]' via location 'file:/path/'
Adding property source: Config resource 'file [/path/application.yml]' via location 'file:/path/'

The config from the server is ignored. quarkus.grpc.server.port in this case, present in both yamls.

But when running my springboot test app with aws and euc1 profiles enabled the following logs are produced:

Adding property source: Config resource 'file [/path/application-euc1.yml]' via location 'file:/path/'
Adding property source: Config resource 'file [/path/application-aws.yml]' via location 'file:/path/'
Adding property source: Config resource 'file [/path/application.yml]' via location 'file:/path/'

Issue with prod

Taking the above application and setting QUARKUS_SPRING_CLOUD_CONFIG_PROFILES=prod,aws,euc1 produces the same log as above, but actually does take the config values from the server, but only the ones in application.yml, ignoring the ones in the euc1 override, and not fetching the aws override at all.

Recap

From my point of view there are two issues.

1. Behaviour is different than spring cloud config client lib
2. Only the prod profile seems to make a difference, and any other profiles are ignored.

Am I making sense? I mean, if this is intended then fine, but it doesn't support all the use cases that the original library does.

[radcortez]

I'll have a look.

Probably we need to get rid of QUARKUS_SPRING_CLOUD_CONFIG_PROFILES and just use QUARKUS_PROFILE. While QUARKUS_SPRING_CLOUD_CONFIG_PROFILES loads the files from the server, QUARKUS_PROFILE activates the profiles in Quarkus.

By default, Quarkus runs in prod profile. Can you also try setting QUARKUS_PROFILE=prod,aws,euc1?

[primoze]

Yes, that applies the fetched config correctly; in this case applying only the main one merged with euc1, ignoring aws, as above (which isn't technically the case; see below).

I missed this the other day: the app actually does fetch all the configs from the server, but does so in three separate batches:

Adding property source: Config resource 'file [/<path>/app.yml]' via location 'file:/<path>/'

Adding property source: Config resource 'file [/<path>/app-aws.yml]' via location 'file:/<path>/'
Adding property source: Config resource 'file [/<path>/app.yml]' via location 'file:/<path>/'

Adding property source: Config resource 'file [/<path>/app-euc1.yml]' via location 'file:/<path>/'
Adding property source: Config resource 'file [/<path>/app.yml]' via location 'file:/<path>/'

So the last profile wins. But the original library fetches them in two:

Adding property source: Config resource 'file [/<path>/app.yml]' via location 'file:/<path>/'

Adding property source: Config resource 'file [/<path>/app-euc1.yml]' via location 'file:/<path>/'
Adding property source: Config resource 'file [/<path>/app-aws.yml]' via location 'file:/<path>/'
Adding property source: Config resource 'file [/<path>/app.yml]' via location 'file:/<path>/'

For reference, here are the urls requested by the test springboot app:

• http://localhost:8888/app/default for the first request
• http://localhost:8888/app/prod,aws,euc1 for the second

While quarkus makes these requests:

• http://localhost:8888/app/prod
• http://localhost:8888/app/aws
• http://localhost:8888/app/euc1

The profiles should all be fetched in a single request, and the default profile request is missing.