Usage of raw quarkus runtime properties without a build

[DGuhr]

Description

At the moment, all quarkus properties are handled as "build" options in keycloak. This leads to a few corner cases:

1. Quarkus has capabilities we don't wrap / maintain (e.g. using syslog logging). In this case, e.g. a syslog server property is environment dependant (think: dev/stage/prod/whatever). At the moment this would always require a rebuild, though the actual quarkus property is a runtime property.

2. Same applies for the runtime datasource properties for additional datasources, as we use (or will use) e.g. here: JDBC-URL, Username, Password are runtime properties in quarkus, so we want to have them runtime config in keycloak, too.

This issue should provide the following capabilities:

• when a quarkus property is a runtime property, but not included in our configuration, it should still be handled as if it is a runtime configuration, so without a rebuild needed. (e.g. syslog properties)
• when a quarkus property is a buildtime property, but not included in our configuration, a build has to be run before starting keycloak for the build property to apply. If no build is done beforehand, the standard quarkus build/runtime mismatch warning is shown. (e.g. quarkus.hibernate.metrics-enabled at the time of writing is not used by us but available as buildtime property in quarkus)
• Auto-build would not trigger a build automatically on quarkus build properties not used in keycloak, because at the time of writing there is no possibility for us to check the general quarkus config if a property there is build- or runtime. (auto-build is a concept that is keycloak-specific, and does not exist in quarkus). I raised this discussion in quarkus for this issue, so it may be changed in quarkus in the future.
• an exception for auto-build compatibility is made for raw quarkus buildtime properties we use for the new UserStorageProvider implementation to add additional datasources (see here), namely quarkus.datasource.<pattern>.db-kind, quarkus.jdbc.<pattern>.jdbc.driver, quarkus.jdbc.<pattern>.jdbc.transactions, quarkus.jdbc.<pattern>.jdbc.enable-metrics (comp. https://quarkus.io/guides/datasource#jdbc-configuration ). When these properties are available in the quarkus.properties file, a build is automatically triggered by our ruleengine. For all other properties, point 2 applies and the standard quarkus warning for the mismatch is shown. The environment-dependant runtime properties for additional datasources like jdbc-url, db-username, db-password etc. would not require a build.

Discussion

No response

Motivation

No response

Details

No response

[sschu]

Thanks @DGuhr !