Re: [infinispan-dev] KUBE_PING changes

2017-07-03 Thread Thomas SEGISMONT 
Hi Bela,

Yes, upgrading to 4.0.3.Final solved the issue.

Thank you!

2017-07-03 10:45 GMT+02:00 Bela Ban :

> Hi Thomas,
>
> has this issue been resolved? Env variables were introduced in 4.0.2
> [1], so you need at least that version of JGroups.
>
> [1] https://issues.jboss.org/browse/JGRP-2166
>
> On 30/06/17 11:40, Thomas SEGISMONT wrote:
> > 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?
> >
> > 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
> >
> > 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.
> >
> > 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 :)
> >
> > 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  > >:
> >
> > 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  > > 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
> >  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
> >  cluster-with.html>
> > > [3]
> > https://github.com/jgroups-extras/jgroups-kubernetes/
> blob/master/README.adoc
> >  blob/master/README.adoc>
> > > [4] https://github.com/jgroups-extras/jgroups-kubernetes
> > 
> > > --
> > >
> > > SEBASTIAN ŁASKAWIEC
> > >
> > > INFINISPAN DEVELOPER
> > >
> > > Red Hat EMEA 
> > >
> > > 
> > >
> > >
> > >
> > > ___
> > > infinispan-dev mailing list
> > > infinispan-dev@lists.jboss.org
> > 
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >

Re: [infinispan-dev] KUBE_PING changes

2017-07-03 Thread Sebastian Laskawiec 
FYI: https://github.com/infinispan/infinispan/pull/5257

But we first need to fix 9.0.x branch :D

On Mon, Jul 3, 2017 at 10:48 AM Bela Ban  wrote:

> Hi Thomas,
>
> has this issue been resolved? Env variables were introduced in 4.0.2
> [1], so you need at least that version of JGroups.
>
> [1] https://issues.jboss.org/browse/JGRP-2166
>
> On 30/06/17 11:40, Thomas SEGISMONT wrote:
> > 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?
> >
> > 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
> >
> > 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.
> >
> > 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 :)
> >
> > 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  > >:
> >
> > 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  > > 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
> >  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
> > <
> http://belaban.blogspot.ch/2017/05/running-infinispan-cluster-with.html>
> > > [3]
> >
> https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/README.adoc
> > <
> 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 
> > >
> > > 
> > >
> > >
> > >
> > > ___
> > > infinispan-dev mailing list
> > > infinispan-dev@lists.jboss.org
> > 
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >

Re: [infinispan-dev] KUBE_PING changes

2017-07-03 Thread Bela Ban 
Hi Thomas,

has this issue been resolved? Env variables were introduced in 4.0.2 
[1], so you need at least that version of JGroups.

[1] https://issues.jboss.org/browse/JGRP-2166

On 30/06/17 11:40, Thomas SEGISMONT wrote:
> 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?
>
> 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
>
> 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.
>
> 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 :)
>
> 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  >:
>
> 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  > 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
>  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 
> >
> > 
> >
> >
> >
> > ___
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org
> 
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> >
>
> --
> Bela Ban | http://www.jgroups.org
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> 
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

Re: [infinispan-dev] KUBE_PING changes

2017-07-03 Thread Sebastian Laskawiec 
On Mon, Jul 3, 2017 at 9:38 AM Thomas SEGISMONT 
wrote:

> Hi Sebastian,
>
> 2017-07-03 8:24 GMT+02:00 Sebastian Laskawiec :
>
>> Hey Thomas,
>>
>> Comments inlined.
>>
>> Thanks,
>> Sebastian
>>
>>
>> On Fri, Jun 30, 2017 at 9:29 PM Thomas SEGISMONT 
>> 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 :
>>>
 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.

>>>
>> h 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 :

> 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  wrote:
>
>> Thanks, Sebastian!
>>
>> I assume testing on GKE and minikube/openshift was successful?
>>
>>
>> On 14/06/17 13:15, Sebastian Laskawiec wrote:
>> > Hey guys,

Re: [infinispan-dev] KUBE_PING changes

2017-07-03 Thread Thomas SEGISMONT 
Hi Sebastian,

2017-07-03 8:24 GMT+02:00 Sebastian Laskawiec :

> Hey Thomas,
>
> Comments inlined.
>
> Thanks,
> Sebastian
>
>
> On Fri, Jun 30, 2017 at 9:29 PM Thomas SEGISMONT 
> 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.


>
>
>>
>> 2017-06-30 11:40 GMT+02:00 Thomas SEGISMONT :
>>
>>> 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)


>
>
>>
>>> 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.
>>>
>>
> h 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.


>
>
>> 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.


>
>
>>
>>> 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 :
>>>
 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  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  in
> Pods.
>

Re: [infinispan-dev] KUBE_PING changes

2017-07-02 Thread Sebastian Laskawiec 
Hey Thomas,

Comments inlined.

Thanks,
Sebastian


On Fri, Jun 30, 2017 at 9:29 PM Thomas SEGISMONT 
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?


>
> 2017-06-30 11:40 GMT+02:00 Thomas SEGISMONT :
>
>> 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


>
>> 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.


>
>> 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.
>>
>
h 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.


> 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.


>
>> 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 :
>>
>>> 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  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  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/jg

Re: [infinispan-dev] KUBE_PING changes

2017-06-30 Thread Thomas SEGISMONT 
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?

2017-06-30 11:40 GMT+02:00 Thomas SEGISMONT :

> 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?
>
> 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
>
> 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.
>
> 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 :)
>
> 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 :
>
>> 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  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  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-cluste
>>> r-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 
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> > ___
>>> > infinispan-dev mailing list
>>> > infinispan-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >
>>>
>>> --
>>> Bela Ban | http://www.jgroups.org
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>>
>> SEBASTIAN ŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red Hat EMEA 
>> 
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] KUBE_PING changes

2017-06-30 Thread Thomas SEGISMONT 
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?

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

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.

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 :)

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 :

> 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  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  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 
>> >
>> > 
>> >
>> >
>> >
>> > ___
>> > infinispan-dev mailing list
>> > infinispan-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>>
>> --
>> Bela Ban | http://www.jgroups.org
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
>
> SEBASTIAN ŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red Hat EMEA 
> 
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] KUBE_PING changes

2017-06-14 Thread Sebastian Laskawiec 
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  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  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 
> >
> > 
> >
> >
> >
> > ___
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Bela Ban | http://www.jgroups.org
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER

Red Hat EMEA 

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] KUBE_PING changes

2017-06-14 Thread Bela Ban 
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  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 
>
> 
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban | http://www.jgroups.org

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev