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 <[email protected]>: > 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 > > > > > >
