All,
On 6/21/23 13:14, bugzi...@apache.org wrote:
https://bz.apache.org/bugzilla/show_bug.cgi?id=66660
--- Comment #20 from Diego Rivera <diego.riv...@armedia.com> ---
(In reply to romain.manni-bucau from comment #16)
Sounds like what you want is to start the cluster only after which means you
assume that none of the N-1 pods serve anything before pod N is started.
Think this is a high assumptiong for tomcat.
If not, DNS service sounds like a correct compromise if you don't want to
watch kubernetes API to not have to setup a service account.
Last option remains to implement a custom membership strategy, with the
specificty of your deployment I think it can be a not so bad option and it
could even make sense to use tomcat cluster events for the instance X to
notify [1;X-1] instance it is started and join the cluster (a bit like
multicast impl but without multicast need)....but really think this is a
very particular deployment mode and I'm not sure it is sane to propagate or
encourage to be honest.
Well, what I want is to start the cluster with not all nodes up, and enable
late-starting nodes to join the cluster successfully. This isn't too far
fetched.
In the olden days of servers and VMs this wasn't an issue b/c the server/VM
hostnames could be expected to be in DNS already.
This no longer applies in the era of ephemeral containers, where they may come
up and down at will and without warning (crash or planned outage, regardless).
Let's assume that I was actually able to start my pods in parallel (I'll grant
you this is an unexpected shortcoming of the application in question, but I
digress), and the DNS names are resolved successfully.
This is possible, works just fine, and I've done it ... before I discovered the
"must start serially" BS I'm having to find a workaround for. However, here's
the catch: if one of the members listed (by hostname, of course) dies, and has
to be replaced, that new member is now unable to rejoin the cluster since the
other nodes in the cluster won't accept it as a member, b/c it's not in the
list of static members, b/c its IP has now changed.
I'm currently fiddling with the MemberImpl code, and I may have a compromise
that works fairly well. I'll submit a preliminary patch to this thread in the
next few hours (without tests, mind you ... just for feedback ... once the
approach is vetted I'll make sure to dot all the t's and cross all the i's).
I don't want to pollute this BZ with this comment because it may be way
off-base. I'm no Tomcat-cluster expert, nor am I more than
passingly-familiar with k8s.
It seems that the problem is trying to define a dynamic cluster with
static membership. Wouldn't switching to dynamic membership solve
everything?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
