I think the external/internal address translation should be provided by the user. I'm working on a prototype here: https://github.com/slaskawi/infinispan/commit/eeeeae7b567fd84946cba90153d7abf2dd0d6641

I will tidy it up and send a pull request later this week.

On Mon, May 22, 2017 at 4:49 PM Tristan Tarrant <ttarrant@redhat.com> wrote:
We would need to provide a way to supply the external address at
runtime, e.g. via JMX.

Tristan

On 5/22/17 2:50 PM, Sebastian Laskawiec wrote:
> Hey Tristan!
>
> I checked this part and it won't do the trick. The problem is that the
> server does not know which address is used for exposing its services.
> Moreover, this address can change with time.
>
> Thanks,
> Sebastian
>
> On Tue, May 9, 2017 at 3:28 PM Tristan Tarrant <ttarrant@redhat.com
> <mailto:ttarrant@redhat.com>> wrote:
>
>     Sebastian,
>     are you familiar with Hot Rod's proxyHost/proxyPort [1]. In server it is
>     configured using external-host / external-port attributes on the
>     topology-state-transfer element [2]
>
>
>
>     [1]
>     https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/configuration/HotRodServerConfigurationBuilder.java#L43
>     [2]
>     https://github.com/infinispan/infinispan/blob/master/server/integration/endpoint/src/main/resources/schema/jboss-infinispan-endpoint_9_0.xsd#L203
>
>
>     On 5/8/17 9:57 AM, Sebastian Laskawiec wrote:
>      > Hey guys!
>      >
>      > A while ago I started working on exposing Infinispan Cluster which is
>      > hosted in Kubernetes to the outside world:
>      >
>      > pasted1
>      >
>      > I'm currently struggling to get solution like this into the
>     platform [1]
>      > but in the meantime I created a very simple POC and I'm testing it
>      > locally [2].
>      >
>      > There are two main problems with the scenario described above:
>      >
>      >  1. Infinispan server announces internal addresses (172.17.x.x)
>     to the
>      >     client. The client needs to remap them into external ones
>     (172.29.x.x).
>      >  2. A custom Consistent Hash needs to be supplied to the Hot Rod
>     client.
>      >     When accessing cache, the Hot Rod Client needs to calculate
>     server
>      >     id for internal address and then map it to the external one.
>      >
>      > If there will be no strong opinions regarding to this, I plan to
>      > implement this shortly. There will be additional method in Hot Rod
>      > Client configuration (ConfigurationBuilder#addServerMapping(String
>      > mappingClass)) which will be responsible for mapping external
>     addresses
>      > to internal and vice-versa.
>      >
>      > Thoughts?
>      >
>      > Thanks,
>      > Sebastian
>      >
>      > [1] https://github.com/kubernetes/community/pull/446
>      > [2] https://github.com/slaskawi/external-ip-proxy
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > infinispan-dev@lists.jboss.org
>     <mailto:infinispan-dev@lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
>
> SEBASTIANŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red HatEMEA <https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER