<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 8, 2018 at 11:47 AM Bela Ban <<a href="mailto:belaban@mailbox.org">belaban@mailbox.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 08/03/18 10:49, Sebastian Laskawiec wrote:<br>
> Hey Bela,<br>
><br>
> I've just stumbled upon this:<br>
> <a href="https://coreos.com/os/docs/latest/cluster-discovery.html" rel="noreferrer" target="_blank">https://coreos.com/os/docs/latest/cluster-discovery.html</a><br>
><br>
> The Etcd folks created a public discovery service. You need to use a<br>
> token and get a discovery string back. I believe that's super, super<br>
> useful for demos across multiple public clouds.<br>
<br>
<br>
Why? This is conceptually the same as running a GossipRouter on a<br>
public, DNS-mapped, IP address...<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The real challenge with cross-cloud clusters is (as you and I<br>
discovered) to bridge the non-public addresses of local cloud members<br>
with members running in different clouds.<br></blockquote><div><br></div><div>I totally agree with you here. It's pretty bad that there is no way for the Pod to learn what is the external Load Balancer address that exposes it. </div><div><br></div><div>The only way I can see to fix this is to write a very small application which will do this mapping. Then the app should use PodInjectionPolicy [1] (or a similar Admission Controller [2]) </div><div><br></div><div>So back to the publicly available GossipRouter - I still believe there is a potential in this solution and we should create a small tutorial telling users how to do it (maybe a template for OpenShift?). But granted - Admission Controller work (the mapper I mentioned the above) is by far more important.</div><div><br></div><div>[1] <a href="https://kubernetes.io/docs/tasks/inject-data-application/podpreset/">https://kubernetes.io/docs/tasks/inject-data-application/podpreset/</a></div><div>[2] <a href="https://kubernetes.io/docs/admin/admission-controllers/">https://kubernetes.io/docs/admin/admission-controllers/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Unless you make all members use public IP addresses, but that's not<br>
something that's typically advised in a cloud env.<br>
<br>
<br>
> What do you think about that? Perhaps we could implement an ETCD_PING<br>
> and just reuse their service or write our own?<br>
<br>
Sure, should be simple. But - again - what's the goal? If<br>
<a href="http://discovery.etcd.io" rel="noreferrer" target="_blank">discovery.etcd.io</a> can be used as a public *permanent* discovery service,<br>
yes, cool<br></blockquote><div><br></div><div>You convinced me - GossipRouter is the right way to go here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Thanks,<br>
> Seb<br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
<br>
--<br>
Bela Ban | <a href="http://www.jgroups.org" rel="noreferrer" target="_blank">http://www.jgroups.org</a><br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div></div>