Run time configuration consumed from VertxWebProcessor.kubernetes()

[dmlloyd]

Describe the bug
A build step (VertxWebProcessor#kubernetes) is consuming a run time configuration object during build time to determine the HTTP listen port. This is not allowed because run time values cannot be resolved (#3516, #3637) or accessed during build time. The run time configuration objects can only correctly be used to pass as proxies to recorders for run time actions (though in this case, it is quite hard to detect invalid accesses to config fields because of the decision to opt for field injection instead of using e.g. a proxy interface for configuration values, so I might still look into directly injecting the config roots into the recorder proxies and drop support for any injection of run time config objects into build steps).

Additional context
Blocks #3516/#3637.

[dmlloyd]

/cc @stuartwdouglas

[geoand]

The KubernetesPortBuildItem is used to populate the Kubernetes resources and is only ever used at build time - meaning that changing the port value at runtime wouldn't affect the Kubernetes code in any way, since none of that code even exists at runtime.

If we can't consume the runtime config value at build time, what is the alternative?
We need to be able to use whatever value is configured in application.properties (or fallback to whatever the HttpConfiguration.port default is), so should we code this logic inside the processor instead of relying on the regular Quarkus config handling?

[stuartwdouglas]

For now I would just directly use MP config to get the values. Long term we might need something better but this is a somewhat odd case.

…

On Mon, 26 Aug 2019 at 17:09, Georgios Andrianakis ***@***.***> wrote: The KubernetesPortBuildItem is used to populate the Kubernetes resources and is only ever used at build time - meaning that changing the port value at runtime wouldn't affect the Kubernetes code in any way, since none of that code even exists at runtime. If we can't consume the runtime config value at build time, what is the alternative? We need to be able to use whatever value is configured in application.properties (or fallback to whatever the HttpConfiguration.port default is), so should we code this logic inside the processor instead of relying on the regular Quarkus config handling? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3677?email_source=notifications&email_token=AACQG6YWOLRMU75YEUOGCHDQGN6R5A5CNFSM4IPBHQB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5DPPFY#issuecomment-524744599>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACQG65XJ4N7WMSBS3P33IDQGN6R5ANCNFSM4IPBHQBQ> .

[geoand]

PR incoming - I agree that the case is somewhat odd and it's the only one I of this sort I know of in the current codebase

[dmlloyd]

The port value might not be present at build time, so reading it from the config only works if the user happened to supply it to the build. Maybe there should just be a separate configuration item for the Kubernetes port?

[geoand]

If the port is not supplied, wouldn't we just use the default http port?

[dmlloyd]

Run time config is read & used at run time, so the port number could change from run to run.

[geoand]

That is true, but the kubernetes resources can't be changed in any case. It's just a file that the users can choose (or not) to use when the they build the application.