Loading...

XML

Word

Printable

Blocked:
False
Blocked Reason:
None
Ready:
False
Affects:

Release Notes
Release Note Type:
Known Issue
Target Release:

8.0.0.GA
Workaround:

Workaround Exists
Workaround Description:

Hide

If the server exhibits such deployment errors which results in a pod that is running and not ready, an analysis of the server boot must be performed to fix the underlying deployment issue and make sure that the server can boot in a correct state.

If the intermittent deployment failure can not be fixed, the startup probe should be change to use the /ready HTTP endpoint so that any boot error would trigger a pod restart.

Show
If the server exhibits such deployment errors which results in a pod that is running and not ready, an analysis of the server boot must be performed to fix the underlying deployment issue and make sure that the server can boot in a correct state. If the intermittent deployment failure can not be fixed, the startup probe should be change to use the /ready HTTP endpoint so that any boot error would trigger a pod restart.
Git Pull Request:
https://gitlab.cee.redhat.com/red-hat-jboss-enterprise-application-platform-documentation/eap8-documentation/-/merge_requests/306/diffs

Customer Impact: In case of Deployment Error, pod is not restarted as expected when :9990/health/live is used as liveness probe.

In EAP8 Python probes were removed and replaced with HTTP `:9990/health/` endpoints.

It turned out Liveness probe `:9990/health/live` does not reflect Deployments errors as python liveness probes used to do in EAP 74.

Note `:9990/health/live` is default liveness probe in

As this is change of behaviour compared to EAP 74 (regression) I am setting initial priority for Blocker for proper triage.

relates to

EAPDOC-1383 Release notes for JBEAP-24257