Closed hernael closed 3 years ago
/cc @vsevel
Does this only happens with the Vault source? Can you try without it?
without vault? sorry but i don't understand well the test that you say me
Yes, are you able to remove Vault and set up the required configuration in application.properties
? I'm trying to rule out if this is something Vault specific or it it is general.
I supposed that database.url
is set up in Vault. You may try to set something up in application.properties
. It doesn't need to be valid, we just need to make sure that the expansion works.
ok, i only replace the db properties referenced by Vault in application.properties (quarkus.datasource.reactive.url, quarkus.datasource.password, quarkus.datasource.username) by equivalent conection params and this works fine.
Additional info: vault oidc properties in application.properties work fine.
In 1.13.CR1 I only added https://github.com/quarkusio/quarkus/pull/15617 and https://github.com/quarkusio/quarkus/pull/15353 does not seem to be related
Do you have other properties set up in Vault? Is this only failing for expanded properties for Vault? Can you provide me a print of ConfigProvider.getConfig().getConfigSources()
? I'm interested in the types, names and order of the sources.
the properties set for vault are:
quarkus.datasource.username
quarkus.datasource.password
quarkus.datasource.reactive.url
quarkus.oidc.auth-server-url
quarkus.oidc.client-id
Q: Is this only failing for expanded properties for Vault?
R: looks like only the quarkus.datasource
expanded for Vault fails
ConfigProvider.getConfig().getConfigSources():
...
please best use this data:
...
I'm not sure but data in previous post maybe is for 1.10.5. Sorry...
@hernael I took a copy and edited the prints, since these contain some environment variables and I don't want you to accidentally expose any sensitive information. I'll have a look tomorrow.
Hi @hernael, I didn't find anything suspicious in the data. Could you iterate over ConfigProvider.getConfig().getConfigSources();
and when you get to the VaultConfigSource
try to retrieve the keys directly from the source?
I've tried locally with a Vault
docker image and a few properties, including starting up a database with expanded properties coming from Vault
and it worked fine. Maybe something else in your setup is breaking the lookup.
I just updated a demo project that i have hosted for issues purposes:
https://github.com/hernael/reactive-demo
Maybe seeing this helps us a little better. Please note that i started the app with intellij in dev mode (just click run in idea)
Ok, let me check
Ok, I believe this is related with https://github.com/quarkusio/quarkus/pull/14960 and more specifically with: https://github.com/quarkusio/quarkus/blob/f4cba6a04ff1df74915297559b62154c49a61fb5/extensions/datasource/deployment-spi/src/main/java/io/quarkus/datasource/deployment/spi/DevServicesDatasourceConfigurationHandlerBuildItem.java#L98-L108
This checks if a DS configuration is available to start / not start a database if you need one. But the check happens in build time when the VaultConfigSource is not available so the expansion fails. For code purpose, it is irrelevant if the value is expanded, since we are only interested if the value is set. I'll provide a fix for this.
In the meanwhile, I recommend to workaround this by setting an empty default in the expression: quarkus.datasource.reactive.url=${database.url:}
(note the final colon in the expansion name).
Sorry for the inconvenience.
ok @radcortez, thanks for the solution!
@radcortez any chance we could have a fix by Tuesday evening?
@radcortez any chance we could have a fix by Tuesday evening?
Yes, doing it right now.
Describe the bug from version 1.13.0 Vault MicroProfile Config Source stopped working to use vault with Databases (Vault MicroProfile Config Source) and OIDC
Expected behavior quarkus fetched vault kv values first and then try verificted dependent properties. In version 1.12.X works fine, but in 1.13.0 does not work
Actual behavior on startup throw error:
Hi @radcortez, @vsevel: please note that this error is equal to old #14707 but instead the releases 1.11.0 it happens in new releases 1.13.0