newbie + kubernetes IpFinder

[Péterfi, Balázs]

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

[dmagda]

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 <[hidden email]> 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
>

[Péterfi, Balázs]

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 <[hidden email]> 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 <[hidden email]>
> 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
> >
>

[Dmitry Pavlov]

Hi Balazs,

I've added you to the list of contributors, so now you can assign the issue.

Ignite does not have any strict/detailed conventions about tickets
(probably someday we'll create some).
Main requirements can be found in
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-TicketsandVersions

My vision about tickets - it is just common sense: Summary in the title,
and in description: Why this ticket should be done (problem), (optional: )
How this change can be done. Reference points: dev lists discussions, test
failures, logs, etc. This particular ticket is quite well described.

Sincerely,
Dmitriy Pavlov

чт, 18 апр. 2019 г. в 10:39, Péterfi, Balázs <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]>
> > 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
> > >
> >
>