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
>

Reply via email to