camel-k icon indicating copy to clipboard operation
camel-k copied to clipboard

fix(trait): camel catalog regression

Open squakez opened this issue 1 year ago • 2 comments

#5378 had introduced a regression on certain traits that were expecting the presence of a Camel Catalog in order to work. These traits can still work using the legacy business logic which were expecting Camel Quarkus as a runtime. These PR amend that behavior and requires the introduction of new parameters for the health trait in order to let the user explicitly configure the path for the different probes we offer.

Knative and KnativeService traits would require the user to forcefully set enabled=true and auto=false in order to let the operator know to skip any check which would require the presence of a catalog, making them work also when a catalog is absent (ie, "sourceless" Integrations).

Notice that the health probes are necessarily part of the runtime specification as they are runtime detail specific (ie, Quarkus probes differ from Springboot probes), therefore, in absence of a catalog, it seems to be the best option to let the user specify the probes path to use. This is defaulting to Quarkus legacy, so it won't require immediate attention by users upgrading. However it's advisable to switch to a new explicit logic as soon as possible as using those default is deprecated and will be removed soon.

For logging, we are defaulting to the Quarkus runtime, but it's also advisable to move soon to an explicit logic where the catalog is missing (ie, setting explicitly the logging camel properties).

Closes #5519

Release Note

fix(trait): camel catalog regression

squakez avatar May 20 '24 13:05 squakez

:heavy_check_mark: Unit test coverage report - coverage increased from 38.2% to 38.4% (+0.2%)

github-actions[bot] avatar May 20 '24 13:05 github-actions[bot]

:heavy_check_mark: Unit test coverage report - coverage increased from 38.2% to 38.4% (+0.2%)

github-actions[bot] avatar May 20 '24 13:05 github-actions[bot]