+++ This bug was initially created as a clone of Bug #1026723 +++ The health servlet is a legacy interface that IMO should not be used at all, marked obsolete and removed as soon as we can. Please make the notification service use the formal supported API to pull engine status. This applies to both setup and hosted. Thanks! --- Additional comment from Sandro Bonazzola on 2013-11-06 04:24:11 EST --- (In reply to Alon Bar-Lev from comment #0) > Please make the notification service use the formal supported API to pull > engine status. import ovirtsdk.api ovirtapi=ovirtsdk.api.API( url='https://sbonazzo.csb/api', username='admin@internal', password='****', ca_file='/etc/pki/ovirt-engine/ca.pem', ) once connection is established (engine running), how may I know if DB is Up? --- Additional comment from Alon Bar-Lev on 2013-11-06 04:35:27 EST --- our application is not initialized if database connection is down... or do you suggest otherwise...? # systemctl stop ovirt-engine # systemctl stop postgresql # systemctl start ovirt-engine # curl -v -k https://admin%40internal:engine@localhost/api # systemctl start postgresql # curl -v -k https://admin%40internal:engine@localhost/api BTW: I do not see our application recovering from database down anyway...
Why have you closed? this is for 3.4... just commit it upstream it will be visible in downstream.
I've just cloned to ovirt-hosted-engine-setup component since the original bug pointed to both engine-setup and hosted-engine setup.
Postponed to 3.6.0 due to authentication issues after SDK changes requiring ssl connection. Probably the best approach is to have a not authenticated API just to check the status of the system instead of authenticating with the SDK but I don't know when we can have it.
Juan, will we keep health servlet in 4.1? If yes, I'm for postponing this to 4.2.
I don't have any good reason to keep or remove that servlet. Do we know what is using it?
I'm aware only of ovirt-live and ovirt-hosted-engine-setup.
If those components use that service and we support them, then I'd say that we can't remove this servlet.