fix(trait): camel catalog regression #5524
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
oscerd
approved these changes
May 20, 2024
|
✔️ Unit test coverage report - coverage increased from 38.2% to 38.4% (+0.2%) |
|
✔️ Unit test coverage report - coverage increased from 38.2% to 38.4% (+0.2%) |
squakez
added
the
trigger native test
gansheer
approved these changes
May 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#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=trueandauto=falsein 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