<div dir="ltr">Hey Rob!<div><br></div><div>Thanks a lot for clarification!</div><div><br></div><div>More comments inlined.</div><div><br></div><div>Thanks</div><div>Sebastian</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 20, 2016 at 12:04 AM, Rob Cernich <span dir="ltr">&lt;<a href="mailto:rcernich@redhat.com" target="_blank">rcernich@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div>A couple of things...<br></div><div><br></div><div>re. volumes:<br></div><div>We also need to consider the mounting behavior for scale down scenarios and for overage scenarios when doing upgrades.  For the latter, OpenShift can spin up pods of the new version before the older version pods have terminated.  This may mean that some volumes from the old pods are orphaned.  We did see this when testing A-MQ during upgrades.  With a single pod, the upgrade process caused the new version to have a new mount and the original mount was left orphaned (another upgrade would cause the newer pod to pick up the orphaned mount, leaving the new mount orphaned).  I believe we worked around this by specifying an overage of 0% during upgrades.  This ensured the new pods would pick up the volumes left behind by the old pods.  (Actually, we were using subdirectories in the mount, since all pods shared the same volume.)<br></div><div><br></div></div></div></blockquote><div><br></div><div>I think PetSets try to address this kind of problems. According to the manual page [11], the storage is linked to the Pod ordinal and hostaname and should be stable. </div><div><br></div><div>[11] <a href="http://kubernetes.io/docs/user-guide/petset/#when-to-use-pet-set">http://kubernetes.io/docs/user-guide/petset/#when-to-use-pet-set</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div></div><div>re. dns:<br></div><div>DNS should work fine as-is, but there are a couple things that you need to consider.<br></div><div>1. Service endpoints are only available in DNS after the pod becomes ready (SVC records on the service name).  Because infinispan attaches itself to the cluster, this meant pods were all started as cluster of one, then merged once they noticed the other pods.  This had a significant impact on startup.  Since then, OpenShift has added the ability to query the endpoints associated with a service as soon as the pod is created, which would allow initialization to work correctly.  To make this work, we&#39;d have to change the form of the DNS query to pick up the service endpoints (I forget the naming scheme).<br></div></div></div></blockquote><div><br></div><div>Yes, I agree. Adding nodes one after another will have significant impact on cluster startup time. However it should be safe to query the cluster (and even put data) during rebalance. So I would say, if a node is up, and cluster is not damaged - we should treat it as ready. </div><div><br></div><div>NB - I proposed a HealthCheck API to Infinispan 9 (currently under development) [12][13]. The overall cluster health can be in one of 3 statuses - GREEN (everything is fine), YELLOW (rebalance in progress), RED (cluster not healthy). Kubernetes/OpenShift readiness probe should check if the status is GREEN or YELLOW. The HealthCheck API is attached to the WF management API so you can query it with CURL or using ispn_cli.sh script.</div><div><br></div><div>[12] <a href="https://github.com/infinispan/infinispan/wiki/Health-check-API">https://github.com/infinispan/infinispan/wiki/Health-check-API</a></div><div>[13] <a href="https://github.com/infinispan/infinispan/pull/4499">https://github.com/infinispan/infinispan/pull/4499</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div></div><div><span style="font-size:12pt">Another thing to keep in mind is that looking up pods by labels allows any pod with the specified label to be added to the cluster.  I&#39;m not sure of a use case for this, but it would allow other deployments to be included in the cluster.  (You could also argue that the service is the authority for this and any pod with said label would be added as a service endpoint, thus achieving the same behavior...probably more simply too.)</span></div></div></div></blockquote><div><br></div><div>I think this is a scenario when someone might try to attach Infinispan in library mode (a dependency in WAR file for example) to the Hot Rod cluster. Gustavo answered question like this a while ago [14].</div><div><br></div><div>[14] <a href="https://developer.jboss.org/message/961568">https://developer.jboss.org/message/961568</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div><span style="font-size:12pt">Lastly, DNS was a little flaky when we first implemented this, which was part of the reason we went straight to kubernetes.  Users were using dnsmasq with wildcards that worked well for routes, but ended up routing services to the router ip instead of pod ip.  Needless to say, there were a lot of complications trying to use DNS and debug user problems with service resolution.</span></div></div></div></blockquote><div><br></div><div>I think a governing headless service [15] is required here (PetSets require a service but considering how Infinispan works, it should be a headless service in my opinion). </div><div><br></div><div>[15] <a href="http://kubernetes.io/docs/user-guide/services/#headless-services">http://kubernetes.io/docs/user-guide/services/#headless-services</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:&quot;times new roman&quot;,&quot;new york&quot;,times,serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><div>Hope that helps,<br></div><div>Rob<br></div><div><br></div><hr><div><div class="h5"><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr">Hey Bela!<div><br></div><div>No no, the resolution can be done with pure JDK.</div><div><br></div><div>Thanks</div><div>Sebastian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 19, 2016 at 11:18 AM, Bela Ban <span dir="ltr">&lt;<a href="mailto:bban@redhat.com" target="_blank">bban@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Sebastian<br><br> the usual restrictions apply: if DNS discovery depends on external libs, then it should be hosted in jgroups-extras, otherwise we can add it to JGroups itself.<span><br> <br> On 19/08/16 11:00, Sebastian Laskawiec wrote:<br> </span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span> Hey!<br> <br> I&#39;ve been playing with Kubernetes PetSets [1] for a while and I&#39;d like<br> to share some thoughts. Before I dig in, let me give you some PetSets<br> highlights:<br> <br></span>   * PetSets are alpha resources for managing stateful apps in Kubernetes<span><br>     1.3 (and OpenShift Origin 1.3).<br></span>   * Since this is an alpha resource, there are no guarantees about<span><br>     backwards compatibility. Alpha resources can also be disabled in<br>     some public cloud providers (you can control which API versions are<br>     accessible [2]).<br></span>   * PetSets allows starting pods in sequence (not relevant for us, but<span><br>     this is a killer feature for master-slave systems).<br></span>   * Each Pod has it&#39;s own unique entry in DNS, which makes discovery<span><br>     very simple (I&#39;ll dig into that a bit later)<br></span>   * Volumes are always mounted to the same Pods, which is very important<span><br>     in Cache Store scenarios when we restart pods (e.g. Rolling Upgrades<br>     [3]).<br> <br> Thoughts and ideas after spending some time playing with this feature:<br> <br></span>   * PetSets make discovery a lot easier. It&#39;s a combination of two<span><br>     things - Headless Services [4] which create multiple A records in<br>     DNS and predictable host names. Each Pod has it&#39;s own unique DNS<br>     entry following pattern: {PetSetName}-{PodIndex}.{<wbr>ServiceName} [5].<br>     Here&#39;s an example of an Infinispan PetSet deployed on my local<br>     cluster [6]. As you can see we have all domain names and IPs from a<br>     single DNS query.<br></span>   * Maybe we could perform discovery using this mechanism? I&#39;m aware of<span><br>     DNS discovery implemented in KUBE_PING [7][8] but the code looks<br>     trivial [9] so maybe it should be implement inside JGroups? @Bela -<br>     WDYT?<br></span>   * PetSets do not integrate well with OpenShift &#39;new-app&#39; command. In<span><br>     other words, our users will need to use provided yaml (or json)<br>     files to create Infinispan cluster. It&#39;s not a show-stopper but it&#39;s<br>     a bit less convenient than &#39;oc new-app&#39;.<br></span>   * Since PetSets are alpha resources they need to be considered as<span><br>     secondary way to deploy Infinispan on Kubernetes and OpenShift.<br></span>   * Finally, the persistent volumes - since a Pod always gets the same<span><br>     volume, it would be safe to use any file-based cache store.<br> <br> If you&#39;d like to play with PetSets on your local environment, here are<br> necessary yaml files [10].<br> <br> Thanks<br> Sebastian<br> <br> <br> [1] <a href="http://kubernetes.io/docs/user-guide/petset/" rel="noreferrer" target="_blank">http://kubernetes.io/docs/<wbr>user-guide/petset/</a><br> [2] For checking which APIs are accessible, use &#39;kubectl api-versions&#39;<br> [3]<br> <a href="http://infinispan.org/docs/stable/user_guide/user_guide.html#_Rolling_chapter" rel="noreferrer" target="_blank">http://infinispan.org/docs/<wbr>stable/user_guide/user_guide.<wbr>html#_Rolling_chapter</a><br> [4] <a href="http://kubernetes.io/docs/user-guide/services/#headless-services" rel="noreferrer" target="_blank">http://kubernetes.io/docs/<wbr>user-guide/services/#headless-<wbr>services</a><br> [5] <a href="http://kubernetes.io/docs/user-guide/petset/#peer-discovery" rel="noreferrer" target="_blank">http://kubernetes.io/docs/<wbr>user-guide/petset/#peer-<wbr>discovery</a><br> [6] <a href="https://gist.github.com/slaskawi/0866e63a39276f8ab66376229716a676" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>slaskawi/<wbr>0866e63a39276f8ab66376229716a6<wbr>76</a><br> [7] <a href="https://github.com/jboss-openshift/openshift-ping/tree/master/dns" rel="noreferrer" target="_blank">https://github.com/jboss-<wbr>openshift/openshift-ping/tree/<wbr>master/dns</a><br> [8] <a href="https://github.com/jgroups-extras/jgroups-kubernetes/tree/master/dns" rel="noreferrer" target="_blank">https://github.com/jgroups-<wbr>extras/jgroups-kubernetes/<wbr>tree/master/dns</a><br> [9] <a href="http://stackoverflow.com/a/12405896/562699" rel="noreferrer" target="_blank">http://stackoverflow.com/a/<wbr>12405896/562699</a><br> [10] You might need to adjust ImageStream.<br> <a href="https://gist.github.com/slaskawi/7cffb5588dabb770f654557579c5f2d0" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>slaskawi/<wbr>7cffb5588dabb770f654557579c5f2<wbr>d0</a><br> </span></blockquote><span><span style="color:rgb(136,136,136)" color="#888888"> <br> -- <br> Bela Ban, JGroups lead (<a href="http://www.jgroups.org" rel="noreferrer" target="_blank">http://www.jgroups.org</a>)<br> <br> </span></span></blockquote></div><br></div></blockquote><div><br></div></div></div></div></div></blockquote></div><br></div></div>