[ https://issues.jboss.org/browse/WFLY-10864?page=com.atlassian.jira.plugin... ] Brian Stansberry edited comment on WFLY-10864 at 12/11/18 9:11 PM: ------------------------------------------------------------------- IMHO if we do anything like this we should keep it very simple, a la our OS health probes at https://github.com/jboss-openshift/cct_module/blob/master/os-eap-probes/a..., which basically check server-state, whether there were errors at boot, whether any deployments are failed. I could also see tracking whether MSC stability could not be reached when executing a mgmt op and failing if that had occurred, as the server is in an unknowable state at that point. If the server booted cleanly and it hasn't subsequently gotten into an MSC unstable state, then if something isn't working "right" that either means a valid configuration, but just not what the user really wanted, or the user executed a management op that failed but they set the flag that prevented rollback. The latter I see little point in trying to account for as it's a silly thing to do on a system that someone would want to monitor for health. Checking for a valid but not really what was wanted configuration (oops, I forgot to add an undertow listener on 8080!) seems like endless work. Note I believe the checks I linked above would find the port collision issue as it would prevent clean boot. was (Author: brian.stansberry): IMHO if we do anything like this we should keep it very simple, a la our OS health probes at https://github.com/jboss-openshift/cct_module/blob/master/os-eap-probes/a..., which basically check server-state, whether there were errors at boot, whether any deployments are failed. I could also see tracking whether MSC stability could not be reached when executing a mgmt op and failing if that had occurred, as the server is in an unknowable state at that point. If the server booted cleanly and it hasn't subsequently gotten into an MSC unstable state, then if something isn't working "right" that either means a a valid configuration, but just not what the user really wanted, or the user executed a management op that failed but they said the flag that prevented rollback. The latter I see little point in trying to account for as it's a silly thing to do on a system that someone would want to monitor for health. Checking for valid but not really what was wanted configuration (oops, I forgot to add an undertow listener on 808!!) seems like endless work. Note I believe the checks I linked above would find the port collision issue as it would prevent clean boot. -- This message was sent by Atlassian Jira (v7.12.1#712002)