Description
In one test with XP image [1] I am experiencing problem of failing rediness probe.
sh-4.2$ python -d /opt/eap/bin/probes/runner.py --debug -c READY --loglevel=DEBUG probe.eap.dmr.EapProbe probe.eap.dmr.HealthCheckProbe DEBUG:__main__:Starting probe runner with args: Namespace(check=[<Status.READY: 8>], debug=True, logfile=None, loglevel='DEBUG', probes=['probe.eap.dmr.EapProbe', 'probe.eap.dmr.HealthCheckProbe']) INFO:__main__:Loading probe: probe.eap.dmr.EapProbe DEBUG:probe.eap.dmr.EapProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=*** INFO:__main__:Loading probe: probe.eap.dmr.HealthCheckProbe DEBUG:probe.eap.dmr.HealthCheckProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=*** INFO:__main__:Probes will fail for the following states: [HARD_FAILURE, FAILURE, NOT_READY] INFO:__main__:Running probes INFO:__main__.ProbeRunner:Running the following probes: [probe.eap.dmr.EapProbe, probe.eap.dmr.HealthCheckProbe] INFO:__main__.ProbeRunner:Running probe: probe.eap.dmr.EapProbe INFO:probe.eap.dmr.EapProbe:Executing the following tests: [probe.eap.dmr.ServerStatusTest, probe.eap.dmr.BootErrorsTest, probe.eap.dmr.DeploymentTest] INFO:probe.eap.dmr.EapProbe:Sending probe request to http://localhost:9990/management DEBUG:probe.eap.dmr.EapProbe:Probe request = { "operation": "composite", "json.pretty": 1, "steps": [ { "operation": "read-attribute", "name": "server-state" }, { "operation": "read-boot-errors", "address": { "core-service": "management" } }, { "operation": "read-attribute", "name": "status", "address": { "deployment": "*" } } ], "address": [] } INFO:urllib3.connectionpool:Starting new HTTP connection (1): localhost DEBUG:urllib3.connectionpool:"POST /management HTTP/1.1" 403 188 DEBUG:probe.eap.dmr.EapProbe:Probe response: <Response [403]> ERROR:probe.eap.dmr.EapProbe:Unexpected failure sending probe request Traceback (most recent call last): File "/s2i-output/server/bin/probes/probe/api.py", line 142, in execute results = self.sendRequest(request) File "/s2i-output/server/bin/probes/probe/dmr.py", line 97, in sendRequest self.failUnusableResponse(response, request, url) File "/s2i-output/server/bin/probes/probe/dmr.py", line 108, in failUnusableResponse unusable = not respDict or not respDict["outcome"] or respDict["outcome"] != "failed" or not respDict["result"] KeyError: 'result' INFO:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned statuses [FAILURE] DEBUG:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned messages "Error sending probe request: 'result'"
Note there is Response [403] which makes me think it will be related with legacy security switch with Elytron.
When I look at CD19 standalon-openshift.xml I see by default management interface is unsecured. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is secured by legacy security ManagementRealm pointing to mgmt-users.properties
In contrast in XP images it is secured by default by management-http-authentication which is pointing to mgmt-users.properties, which is empty by default. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is filled with that user
<management-interfaces> <http-interface http-authentication-factory="management-http-authentication" console-enabled="false"> <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/> <socket-binding http="management-http"/> </http-interface> </management-interfaces>
I think both approaches should be consistent (no matter if legacy or Elytron). E.g. unsecured by default and secured when ADMIN_PASSWORD, ADMIN_USERNAME specified (like in case of CD19)
[1] docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel7:EAP7-1484