https://bz.apache.org/bugzilla/show_bug.cgi?id=66660
Diego Rivera <diego.riv...@armedia.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |---
Status|RESOLVED |REOPENED
--- Comment #14 from Diego Rivera <diego.riv...@armedia.com> ---
(In reply to jfclere from comment #13)
> The DNS service and the logic in tomcat cluster expects the pods to be ready
> otherwise the whole stuff is useless.
> The lookup is done on the service which returns all the available pods
> Probably your problems are related to the readyness probe you are using.
This is an incorrect assumption. The service only returns its own IP. This is
by design. At least, that's how it's worked on every K8s instance I've worked
with (vanilla K8s and EKS).
Also, this specific application doesn't support concurrent startup, so *it's
impossible for all pods to exist at the same time*. Hence the need to add the
"concept" (if you will) of an *expected member* that may not be available when
the first pod comes up (b/c the other pods may not even exist yet).
Once the first pod becomes ready, the 2nd pod will be created, and eventually
come online. Then the 3rd, 4th, etc...
Therefore it's OK for the cluster members to all know that EVENTUALLY a certain
set of pods will be part of the cluster. The problem is that this is not
possible to achieve without access to the K8s API, and I've already explained
why this is not a desirable option.
This isn't something that can be addressed with the existing code (I've
checked), so I'm going to take the (probably unwelcome) step of reopening the
ticket.
So, again, the DNS Provider won't work b/c the service won't return all pod
IP's (it can't, by design, due to DNS caching!), and the K8s provider requires
access to the K8s API which in some of our deployments won't be allowed.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
