quarkus: Regression 3.3.0 config quarkus.config.locations with vault
Describe the bug
When switching from 3.2.4 to 3.3.0 , loading properties from vault does not work anymore when using quarkus.config.locations. It may apply to other config source extensions. Not sure at this point.
Expected behavior
property should be loaded from vault, as in 3.2.4
Actual behavior
the property is not loaded.
How to Reproduce?
create an application with quarkus 3.3.0 and vault extension 3.1.0 .
start a vault like in the quickstart:
docker run --rm --cap-add=IPC_LOCK -e VAULT_ADDR=http://localhost:8200 -p 8200:8200 -d --name=dev-vault vault
docker logs dev-vault
...
# get Root Token: from the logs
docker exec -it dev-vault sh
...
# inside shell
export VAULT_TOKEN=...
vault kv put secret/myapps/vault-quickstart/config a-private-key=123456
in a directory somewhere outside the app:
- create a
configdirectory - create 2 files:
application.propertiesandbase-application.properties
in application.properties, add:
quarkus.config.locations=./config/base-application.properties
in base-application.properties, add:
config_ordinal=255
#quarkus.http.port=8090
quarkus.vault.kv-secret-engine-version=2
quarkus.vault.url=http://localhost:8200
quarkus.vault.tls.skip-verify=true
quarkus.vault.secret-config-kv-path.quickstart=myapps/vault-quickstart/config
quarkus.vault.authentication.client-token=<root token>
foo=${quickstart.a-private-key}
quickstart.a-private-key=xxx
quarkus.log.category."io.quarkus.vault".level=DEBUG
in GreetingResource:
@ConfigProperty(name = "foo")
String foo;
@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/prop")
public String helloProp() {
return foo;
}
start the application. you get:
$ java -Dquarkus.http.port=8090 -jar ../target/quarkus-app/quarkus-run.jar
Failed to load config value of type class java.lang.String for: foo
it works if:
- you switch to quarkus
3.2.4and vault3.0.0 - you add property
quickstart.a-private-key=xxxtobase-application.properties - you move the content of
basde-application.propertiesintoapplication.properties
Output of uname -a or ver
No response
Output of java -version
17
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.3.0
Build tool (ie. output of mvnw --version or gradlew --version)
No response
Additional information
No response
About this issue
- Original URL
- State: closed
- Created 10 months ago
- Comments: 36 (36 by maintainers)
The reason we do it is that you may have configuration required for build time and also readable at runtime. We call this recording configuration. The purpose is to avoid failing the application run because a configuration is missing. It also makes sure that the configuration cannot be overridden, since you usually don’t want the same configuration that was used at build time to have a different value at runtime.