Hi Denis, Thanks for your reply. I've created a ticket ( https://issues.apache.org/jira/browse/IGNITE-11771) for the first part of my email. Could you please have a look at it to make sure it follows your conventions? If all good can you please assign to me so I can start working on it?
As for the second part of my email: is there any way to control which pods should form a cluster, or will always all of them join to one big cluster? Thanks, Balazs On Wed, 17 Apr 2019 at 19:19, Denis Magda <[email protected]> wrote: > Hello Balazs, > > Thanks for reaching the community out. Certainly, we'll appreciate if you > contribute your changes back. Could you please create a ticket in JIRA and > open the pull-request? Someone from the community will review and accept > your improvements. > > Just in case, you can find more on contribution here: > https://ignite.apache.org/community/contribute.html#contribute > > - > Denis > > > On Wed, Apr 17, 2019 at 8:03 AM Péterfi, Balázs <[email protected]> > wrote: > > > Hi All, > > > > First of all I wanted to say hi as I've just joined to the list! > > > > Secondly, I'm moving one of my apps to Kubernetes and found > > the ignite-kubernetes lib for finding the pods for the cluster. After > > playing with it a bit I found out that it won't work for me, because it > > only collects the IPs for the pods that are in a ready state. My problem > > with that is when my app is starting it warms up the cache which takes > some > > time and only when this is done will it have a ready state in k8s. But at > > that point all my pods have started a single node cluster and they end up > > in a split-brain scenario (not to mention that they all did the cache > > warm-up which is a waste). In Hazelcast they have a flag to include > > non-ready pods as well which solves the issue. I have an implementation > for > > that and would be happy to add it in the original IpFinder with some > > configuration to control that behavior, unless someone here tells me > > otherwise. > > > > There is another change I did on the original version which is to prevent > > two ReplicaSets of the same app joining to each-other's cluster. This is > a > > must have for me when deploying a new version while leaving the old one > > running until the warm-up finishes. I couldn't find any configuration > that > > prevents this happening so I changed the IpFinder to only look for pods > > from the same ReplicaSet. I wonder if there is any other solution for > this > > issue? > > > > Best regards, > > Balazs > > >
