Repository navigation
HBase Restserver startup probe failing with external listeners #714
Description
Activity
One related question is why are REST servers now special cased?
The original issue wanted them advertised. We decided to not do that as suggested (add them to the discovery map). Instead, every REST server Pod now has it's own listener service while the other roles (
masterandregionserver) do not.IMO especially for REST servers this is too much. Clients never need to work with all or with a specific instance of them. These are not data bearing servers. There is no value added in having a service per http(s) Pod.
Instead, every REST server Pod now has it's own listener service while the other roles (
masterandregionserver) do not.Can't comment on any of your other points, but at least for this one:
masterandregionserverPods also have a listener service per Pod. Not sure if that changes anything.
- linked a pull request that will close this issuefix: rename hbase-site.xml keys for restserver advertisement #716
on Nov 18, 2025 Release Note in #716 (comment)
- moved this from Development: In Progress to Development: Done in Stackable Engineering
on Nov 20, 2025
Metadata
Metadata
Assignees
Type
Projects
- Status
#708 revealed in weekly tests that the restserver startup probe is using port
8080(the default rest port) instead of the one assigned by the listener, same for HBase restserver itself which before #708 used the default port8080instead of getting assigned the listener port. Maybe other usages of that as well. Subsequently the Pod never gets ready.Goal would be to analyze and fix the problems.
Description about the analyzed problem and the solution are found in #716
Acceptance