Quarkus: Support for Service Binding Specification to pick up external service configuration "automagically"

[maxandersen]

Description
The k8s service binding specification has a notion of "application projection" which defines how directory with files gets used to map a configuration of external services, like a postgres database or a kafka source.

My thinking is that Quarkus should have a way for user to load that configuration to be available in two ways:

1) as raw configuration variables that could be referred in application.properties i.e.

quarkus.datasource.db-kind=postgresql
quarkus.datasource.username=${qurarkus.service-binding.xyz.username}

2) have ability for extensions to provide "magic detectors" (for lack of a better word) that will be consulted to perform a automagic mapping of the external services into quarkus configuration.

These detectors would be service specific, i.e. a PostgresSQLServiceBinding class would based on the always present type map the known settings into quarkus.datasource configs. Similar with a MySQL or whatever known set of services.

Implementation ideas
Be based on similar ideas used for other config resources and priorities - just that in this case we are able to do more service specific setup removing need for users always have to manually do #1 option above.

[geoand]

For reference, he is how Spring Cloud handles this use case: https://github.com/spring-cloud/spring-cloud-bindings

[geoand]

I went through the Spring Cloud code and the specification and it seems to me that from the spec the only part we care about is: https://github.com/k8s-service-bindings/spec#application-projection.

Here is what I propose we do to implement this:

• Create a new extension (something like quarkus-kubernetes-service-binding) which will hook into Quarkus' bootstrap config (we want bootstrap config because we need to allow the user to configure the FileSystem root path where bindings will be looked up and because we also need to let the user control whether this binding is enabled or not). The extension will use the file system to create the corresponding Binding representations. This extension will also define a Service interface whose objective is to convert a binding into a set of properties.
• Each Quarkus extension that could benefit from these bindings (like Agroal, Kafka, whetever) would provide an implementation of the Service mentioned above and thus convert the binding into the runtime properties it requires.
• Finally the new extension would convert these properties would finally be used to implement org.eclipse.microprofile.config.spi.ConfigSourceProvider.

@radcortez WDYT?
I can whip up a quick PoC if you like, demonstrating what I have in mind.

[machi1990]

I went through the Spring Cloud code and the specification and it seems to me that from the spec the only part we care about is: https://github.com/k8s-service-bindings/spec#application-projection.

Here is what I propose we do to implement this:

• Create a new extension (something like quarkus-kubernetes-service-binding) which will hook into Quarkus' bootstrap config (we want bootstrap config because we need to allow the user to configure the FileSystem root path where bindings will be looked up and because we also need to let the user control whether this binding is enabled or not). The extension will use the file system to create the corresponding Binding representations. This extension will also define a Service interface whose objective is to convert a binding into a set of properties.
• Each Quarkus extension that could benefit from these bindings (like Agroal, Kafka, whetever) would provide an implementation of the Service mentioned above and thus convert the binding into the runtime properties it requires.
• Finally the new extension would convert these properties would finally be used to implement org.eclipse.microprofile.config.spi.ConfigSourceProvider.

@radcortez WDYT?
I can whip up a quick PoC if you like, demonstrating what I have in mind.

Exactly what I had in mind. I'd would be willing to help wherever my help will be needed.

[geoand]

@machi1990 thanks! I'll let you know :)

[radcortez]

Sure, go ahead. Also have a look into this:
https://github.com/smallrye/smallrye-config/tree/master/examples/configmap

And:
https://github.com/smallrye/smallrye-config/blob/master/implementation/src/main/java/io/smallrye/config/ConfigSourceFactory.java

It may help.

Ideally, I would prefer to have this implemented in SR Config side and then integrated in Quarkus.

[geoand]

OK, I'll start a PoC in Quarkus itself (as it will be faster to see the whole picture) and then we discuss it and move the proper parts to SR Config.

[geoand]

Here is my prototype: https://github.com/quarkusio/quarkus/pull/13737

It's still very unpolished obviously, but let me know what you think of the general idea

[wtrocki]

@geoand I have done some service binding services if you would like to test this let me know.

Reviewed PR. No specific comments

[geoand]

@wtrocki thanks a lot for offering!

If you woule like to test the PR as is, feel free to do so! Otherwise I can ping you when it is merged

[geoand]

https://github.com/quarkusio/quarkus/pull/13737 implements the basic functionality, but I'll reopen the issue as we still need to add the rest of the "mappings" and create some integration tests.

@machi1990 would you be willing to take on that work, or at least part of it?

@wtrocki do you want to try this out? Do you need any help on my part?