Open lburgazzoli opened 8 months ago
@davsclaus ^^
@lburgazzoli I think this can intersect with the work I'm about to retake of https://github.com/apache/camel-k/pull/5096. Right now, using as an example reference the Quarkus runtime, the service is returning the following result:
{
"status": "DOWN",
"checks": [ {
"name": "camel-routes",
"status": "DOWN",
"data": {
"route.id": "route1",
"route.status": "Stopped",
"check.kind": "READINESS"
}
}]
}
Do you think can be this enough to start some development which may eventually be enhanced with any future work on Camel core?
I don't think this should be something to be included in the health endpoint but rather a dedicated endpoint
I don't think this should be something to be included in the health endpoint but rather a dedicated endpoint
Clear. What I mean is, while this is available on Camel core, should we start the development on the operator side? I guess that, when the new development is ready, then, we can easily change the endpoint to the new one. In the while, however, we'd be preparing all the required stuff on the operator side.
BTW, this I was meaning to include the info that are already on the health endpoint
I'd personally wait to see how/if things would be implemented in camel core
This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!
Requirement
List Camel's endpoint in the integrations status
Problem
The camel-k operator can project the status of the Camel context/routes/etc to the Integration' status by scraping the health endpoint so that tools can get the status of the routes without having to interact with the running process.
It would be nice to also have information about the endpoints registered with the Camel Context so as an example, advanced tools can draw a topology
Proposal
The Camel runtime could optionally expose some additional information, like those exposed by the camel-console but in a production ready way (read only, minimal data).
This production ready console Could be integrated with Spring Boot actuators and Quarkus management interface.
The camel-k operator could then grab such data and project it to the integration status:
Tools like HawtIO, OpenShift DevConsole could then be able to draw a topology of the existing integration and 3rd party systems.
Open questions
No response