Quarkus: ENV Variables doesn't work anymore with Quarkus 0.20.0

[elamotte7]

Describe the bug
I am upgrading quarkus 0.19.1 to 0.20.0.

First kubernetes crash during the Unit tests, but there is already an issue opened.

Secondly, when I launch an "mvn clean install", the result for my unit test is :
...
Unknown level "${CONSOLE_LOG_LEVEL:DEBUG}"
Caused by: java.lang.IllegalArgumentException: Unknown level "${CONSOLE_LOG_LEVEL:DEBUG}"

It seems there is a regression, and the environment variable is not interpreted/ignored as before.

Then i remove all the env var for my test in applications.properties, but i let the ones for the dev and prod mod.
And the result is :
[INFO] --- quarkus-maven-plugin:0.20.0:build (default) @ backend ---
[INFO] [io.quarkus.deployment.QuarkusAugmentor] Beginning quarkus augmentation
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:0.20.0:build (default) on project backend: Failed to build a runnable JAR: Failed to build a runner jar: Failed to augment application classes: Unknown level "${CONSOLE_LOG_LEVEL:DEBUG}" -> [Help 1]

Clearly, it seems that quarkus can't manage env var and default value anymore.

Configuration

# Add your application.properties here, if applicable.
quarkus.log.console.level=${CONSOLE_LOG_LEVEL:DEBUG}

Environment (please complete the following information):

• Output of uname -a or ver:
  Darwin macbook-pro 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64

• Output of java -version:
  java version "11.0.3" 2019-04-16 LTS
  Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
  Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)

• GraalVM version (if different from Java):
  N/A

• Quarkus version or git rev:
  0.20.0

[gsmet]

First kubernetes crash during the Unit tests, but there is already an issue opened.

Which one is it?

[gsmet]

Could you create a failing reproducer (something that worked before with 0.19.1 and now fails with 0.20.0)?

Thanks!

[elamotte7]

First kubernetes crash during the Unit tests, but there is already an issue opened.

Which one is it?

3465

[elamotte7]

Could you create a failing reproducer (something that worked before with 0.19.1 and now fails with 0.20.0)?

Thanks!

Have a look @ https://github.com/elamotte7/quarkus.git

this is a complete example of all the features we are using on my project.

There are two branches, 0.19.1 and 0.20.0

Hope it can be helpful

[elamotte7]

Same behaviour with quarkus 0.21.1

see https://github.com/elamotte7/quarkus/tree/0.21.1

[gsmet]

@gwenneg would you be interested in taking a look at what's happening here?

It would be nice to have it fixed before the next release so I'm looking for a volunteer :).

[gwenneg]

@gsmet I actually already took a quick look at this one without finding a way to fix the issue. I will investigate this again.

[gsmet]

Did you understand what was going on and the difference between the 2 versions? That might ring a bell for someone.

[gwenneg]

The regression may be a consequence of #3263. If I'm not mistaken, before this commit, there was a property "expansion" being performed on quarkus.log.console.level and now the expansion is no longer done. During this expansion, its value was transformed from ${CONSOLE_LOG_LEVEL:DEBUG} to DEBUG.

[gwenneg]

@gsmet I just confirmed locally that reverting #3263 fixes this issue. What should we do about it? Wait for @dmlloyd's return before changing anything? Try fixing it without a revert (I'm really not sure about how to do that)? Revert it now to fix the regression in 0.22.0?

[gsmet]

@dmlloyd should be back from PTO today AFAICS so better ask him the question.

@dmlloyd could you take a look at that one? It's an important regression that would need fixing before the next release. @elamotte7 provided a reproducer.

[dmlloyd]

It's probably an easy fix, but I'll need a full stack trace. I'm playing catch-up with emails and stuff for now so if you want to post one here it'll save me some time. Otherwise once my backlog is cleared I'll try out the reproducer.

[gwenneg]

Here's the stacktrace:

23:25:11,040 ERROR [io.qua.dev.DevModeMain] Failed to start quarkus: java.lang.IllegalArgumentException: Unknown level "${CONSOLE_LOG_LEVEL:DEBUG}"
    at org.jboss.logmanager.LogContext.getLevelForName(LogContext.java:203)
    at io.quarkus.runtime.logging.LevelConverter.convert(LevelConverter.java:22)
    at io.quarkus.runtime.logging.LevelConverter.convert(LevelConverter.java:15)
    at io.smallrye.config.SmallRyeConfig.convert(SmallRyeConfig.java:133)
    at io.smallrye.config.SmallRyeConfig.getOptionalValue(SmallRyeConfig.java:98)
    at io.quarkus.runtime.configuration.ConfigUtils.getOptionalValue(ConfigUtils.java:92)
    at io.quarkus.deployment.configuration.ObjectConfigType.acceptConfigurationValueIntoGroup(ObjectConfigType.java:94)
    at io.quarkus.deployment.configuration.GroupConfigType.acceptConfigurationValueIntoLeaf(GroupConfigType.java:238)
    at io.quarkus.deployment.configuration.ObjectConfigType.acceptConfigurationValue(ObjectConfigType.java:76)
    at io.quarkus.deployment.configuration.ConfigDefinition.loadConfiguration(ConfigDefinition.java:492)
    at io.quarkus.deployment.ExtensionLoader.loadStepsFrom(ExtensionLoader.java:219)
    at io.quarkus.deployment.ExtensionLoader.loadStepsFrom(ExtensionLoader.java:137)
    at io.quarkus.deployment.QuarkusAugmentor.run(QuarkusAugmentor.java:75)
    at io.quarkus.runner.RuntimeRunner.run(RuntimeRunner.java:107)
    at io.quarkus.dev.DevModeMain.doStart(DevModeMain.java:180)
    at io.quarkus.dev.DevModeMain.start(DevModeMain.java:94)
    at io.quarkus.dev.DevModeMain.main(DevModeMain.java:66)

[dmlloyd]

That was quick, thanks :)

[dmlloyd]

Notes (mostly to myself): basically the problem is trying to populate actual config object instances for run time config roots. Really we shouldn't be converting the values or populating the objects. We should just be noting the raw values to record back into the default values file for run time.

[gsmet]

@dmlloyd so was the issue fixed by the changes of the referenced PRs? Or we need a fix in the config code?

[dmlloyd]

No, those changes just set up the necessary fixes. Still working on it.

[FreifeldRoyi]

I got a similar problem with 0.23.2. I had to revert to 0.22.0 in order to deploy my changes.
I have a KAFKA_SERVER env var that wasn't resolved (kafka producer logs showed bootstrap.servers = [${KAFKA_SERVER}]), but other env vars worked.
Also, locally it worked great for both versions... Not sure how to reporo it. Any ideas?

[FreifeldRoyi]

I got a similar problem with 0.23.2. I had to revert to 0.22.0 in order to deploy my changes.
I have a KAFKA_SERVER env var that wasn't resolved (kafka producer logs showed bootstrap.servers = [${KAFKA_SERVER}]), but other env vars worked.
Also, locally it worked great for both versions... Not sure how to reporo it. Any ideas?

If it helps... Docker version of 0.23.2 did not work locally

[elamotte7]

The issue is solved with 1.1.0.CR1 many thanks