On Mon, Jul 3, 2017 at 9:38 AM Thomas SEGISMONT <tsegismont(a)gmail.com>
wrote:
Hi Sebastian,
2017-07-03 8:24 GMT+02:00 Sebastian Laskawiec <slaskawi(a)redhat.com>:
> Hey Thomas,
>
> Comments inlined.
>
> Thanks,
> Sebastian
>
>
> On Fri, Jun 30, 2017 at 9:29 PM Thomas SEGISMONT <tsegismont(a)gmail.com>
> wrote:
>
>> Also, it seems infinispan-cloud 9.0.3.Final depends on JGroups 0.9.1.
>>
>> Do you plan to release another 9.0.x version which depends on
>> 1.0.0.Beta1 or later? If so, is there a target date?
>>
>
> No, I didn't plan to backport it to 9.0.x branch. The implementation is
> pretty new and I wanted to play with it a little bit more before make it
> "stable".
>
> Could you please tell me why do you need it?
>
On Openshift S2I environments, a pod can only expose a predetermined set
of ports. Of course the administrator can customize this set, but in some
cases (e.g. openshift.io) it is very unlikely that the extra port is
added.
That's a fair point. And there's no workaround for this. Ok, I'll do a
backport than.
>
>
>>
>> 2017-06-30 11:40 GMT+02:00 Thomas SEGISMONT <tsegismont(a)gmail.com>:
>>
>>> Hi everyone,
>>>
>>> Thank you for this great work, the dependency diet and the extra port
>>> removal are both very useful. The extra port removal is key to enable
>>> Vert.x clustering in Openshift S2I environments.
>>>
>>> I tried the new KUBE_PING (beta1) with vertx-infinispan and it worked
>>> fine. I have a few questions though.
>>>
>>> I couldn't configure it with env variables. Before you ask, yes I
>>> noticed the name changes ;-) I only had a quick look at JGroups config code
>>> but it seems it only resolves system properties. Did it work for you
>>> because you tried with an Infinispan server?
>>>
>>
> Could you please tell me what is the JGroups version you're running on? I
> think environment variables support requires >= 4.0.3.Final [1].
>
> [1]
>
https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/pom.xml#L56
>
This explains it. I use the version of JGroups which comes with ISPN
9.0.0.Final (4.0.1.Final)
Yeah, I will also bump it up. I hope Dan and Pedro will be OK with that.
>
>
>>
>>> Since I couldn't configure it externally I had to create a custom
>>> JGroups file. Usually, we recommend [1] Vert.x users to add the
>>> infinispan-cloud dependency and a system property:
>>> -Dvertx.jgroups.config=default-configs/default-jgroups-kubernetes.xml
>>>
>>
> +1, that's the correct way to do it. I think bumping up JGroups version
> might solve your problem here.
>
Yes. Upgrading JGroups that solved the issue.
>
>
>>
>>> My custom JGroups file is a just a copy of
>>> default-configs/default-jgroups-kubernetes.xml in which I added the
>>> masterHost and namespace properties.
>>>
>>
> hmmmm that's odd. Why do you need to change masterHost? The default
> should be fine in 99% of the use cases. The namespace is a separate thing
> and in most of the cases a user should set it to his own project.
>
I needed to set the masterHost via a sysprop as my older version of
JGroups wouldn't lookup env vars. With 4.0.3.Final I don't need it anymore.
Ok, understood.
>
>
>> Is it still recommended to use the
>>> default-configs/default-jgroups-kubernetes.xml stack ? Or is any change
>>> planned after the KUBE_PING changes?
>>> I wouldn't expect a protocol implementation change to impact a stack
>>> configuration but they say there are no stupid questions :)
>>>
>>
> No no, using default-jgroups-kubernetes.xml is still necessary (and there
> are no plans to change it in the future). Using specific transport is tied
> with your deployment model. In most of the cases in Kubernetes and
> OpenShift you should use KUBE_PING. Your network configuration might
> support multicasting and then you'd probably need to check if UDP is not
> performing better. You may also use StatefulSets and try out DNS_PING.
>
> As you can see there are many different combinations of protocols you
> might use. Recommending default config shipped with infinispan-cloud is a
> way to go here in my opinion.
>
OK. I had no plans to try my own stack for Openshift really :) Just wanted
to make sure the new KUBE_PING doesn't impact the infinispan-cloud default
Kubernetes stack.
No no... it should be fine.
>
>
>>
>>> Thank you,
>>> Thomas
>>>
>>>
>>> [1]
>>>
http://vertx.io/docs/vertx-infinispan/java/#_configuring_for_openshift_3
>>>
>>>
>>> 2017-06-15 8:21 GMT+02:00 Sebastian Laskawiec <slaskawi(a)redhat.com>:
>>>
>>>> Yep, no problems found!!!
>>>>
>>>> I had also impression that the new implementation is "faster".
Though
>>>> I haven't measured it... it just my impression.
>>>>
>>>> Awesome work Bela!
>>>>
>>>> On Thu, Jun 15, 2017 at 7:42 AM Bela Ban <belaban(a)mailbox.org>
wrote:
>>>>
>>>>> Thanks, Sebastian!
>>>>>
>>>>> I assume testing on GKE and minikube/openshift was successful?
>>>>>
>>>>>
>>>>> On 14/06/17 13:15, Sebastian Laskawiec wrote:
>>>>> > Hey guys,
>>>>> >
>>>>> > Just a heads up, I've just created a PR that upgrades
KUBE_PING to
>>>>> > 1.0.0.Beta1 [1]. As you probably seen in [2], 1.0.0.Beta1 was
>>>>> completely
>>>>> > rewritten and might behave slightly differently.
>>>>> >
>>>>> > Here is a summary of changes:
>>>>> >
>>>>> > * The latest KUBE_PING doesn't require embedded HTTP
server for
>>>>> > discovery. Thus it is no longer required to expose port 8888
in
>>>>> Pods.
>>>>> > * The number of dependencies has been decreased. Currently we
only
>>>>> > require JGroups and OAuth library.
>>>>> > * The new KUBE_PING works only with JGroups 4. There will be
no
>>>>> > JGroups 3 support.
>>>>> > * Some of the environmental variables were shortened and we
>>>>> removed
>>>>> > `OPENSHIFT` prefix. So if you use
>>>>> `OPENSHIFT_KUBE_PING_NAMESPACE`,
>>>>> > you will need to change it to `KUBERNETES_NAMESPACE`.
Please
>>>>> refer
>>>>> > to [3] for more information.
>>>>> >
>>>>> > I also switched default branch in Kubernetes Ping repository to
>>>>> master [4].
>>>>> >
>>>>> > Thanks,
>>>>> > Sebastian
>>>>> >
>>>>> > [1]
https://github.com/infinispan/infinispan/pull/5201
>>>>> > [2]
>>>>>
http://belaban.blogspot.ch/2017/05/running-infinispan-cluster-with.html
>>>>> > [3]
>>>>>
https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/README.adoc
>>>>> > [4]
https://github.com/jgroups-extras/jgroups-kubernetes
>>>>> > --
>>>>> >
>>>>> > SEBASTIAN ŁASKAWIEC
>>>>> >
>>>>> > INFINISPAN DEVELOPER
>>>>> >
>>>>> > Red Hat EMEA <
https://www.redhat.com/>
>>>>> >
>>>>> > <
https://red.ht/sig>
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > infinispan-dev mailing list
>>>>> > infinispan-dev(a)lists.jboss.org
>>>>> >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> >
>>>>>
>>>>> --
>>>>> Bela Ban |
http://www.jgroups.org
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> --
>>>>
>>>> SEBASTIAN ŁASKAWIEC
>>>>
>>>> INFINISPAN DEVELOPER
>>>>
>>>> Red Hat EMEA <
https://www.redhat.com/>
>>>> <
https://red.ht/sig>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
>
> SEBASTIAN ŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red Hat EMEA <
https://www.redhat.com/>
> <
https://red.ht/sig>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <
https://www.redhat.com/>
<
https://red.ht/sig>