<div dir="ltr">cattle vs pet monitoring is something I struggle with TBH...<div><br></div><div>It doesn't make much sense to keep all data about all elements of the cattle as you are less interested by the performance of 1 member but more about the overall performance.</div><div><br></div><div>With auto scaling, new containers are created/removed. You add one, you remove it, you read one, there is no continuation unlike when you restart a server... A configuration change is also not a continuation anymore, it's a whole new image, whole new container (in good practice at least)</div><div><br></div><div>IMO we should keep thinking about those, and think more in terms of collection for the cases when Middleware is running in (immutable) containers...</div><div><br></div><div>Thomas</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 3, 2016 at 11:44 AM, Heiko W.Rupp <span dir="ltr"><<a href="mailto:hrupp@redhat.com" target="_blank">hrupp@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<br>
[ CC to Federico as he may have some ideas from the Kube/OS side ]<br>
<br>
Our QE has opened an interesting case:<br>
<br>
<a href="https://github.com/ManageIQ/manageiq/issues/9556" rel="noreferrer" target="_blank">https://github.com/ManageIQ/manageiq/issues/9556</a><br>
<br>
where I first thought WTF with that title.<br>
<br>
But then when reading further it got more interesting.<br>
Basically what happens is that especially in environments like<br>
Kube/Openshift,<br>
individual containers/appservers are Kettle and not Pets: one goes down,<br>
gets<br>
killed, you start a new one somewhere else.<br>
<br>
Now the interesting question for us are (first purely on the Hawkular<br>
side):<br>
- how can we detect that such a container is down and will never come up<br>
with that id again (-> we need to clean it up in inventory)<br>
- can we learn that for a killed container A, a freshly started<br>
container A' is<br>
the replacement to e.g. continue with performance monitoring of the app<br>
or to re-associate relationships with other items in inventory-<br>
(Is that even something we want - again that is Kettle and not Pets<br>
anymore)<br>
- Could eap+embedded agent perhaps store some token in Kube which<br>
is then passed when A' is started so that A' knows it is the new A (e.g.<br>
feed id).<br>
- I guess that would not make much sense anyway, as for an app with<br>
three app servers all would get that same token.<br>
<br>
Perhaps we should ignore that use case for now completely and tackle<br>
that differently in the sense that we don't care about 'real' app<br>
servers,<br>
but rather introduce the concept of a 'virtual' server where we only<br>
know<br>
via Kube that it exists and how many of them for a certain application<br>
(which is identified via some tag in Kube). Those virtual servers<br>
deliver<br>
data, but we don't really try to do anything with them 'personally',<br>
but indirectly via Kube interactions (i.e. map the incoming data to the<br>
app and not to an individual server). We would also not store<br>
the individual server in inventory, so there is no need to clean it<br>
up (again, no pet but kettle).<br>
In fact we could just use the feed-id as kube token (or vice versa).<br>
We still need a way to detect that one of those kettle-as is on Kube<br>
and possibly either disable to re-route some of the lifecycle events<br>
onto Kubernetes (start in any case, stop probably does not matter<br>
if he container dies because the appserver inside stops or if kube<br>
just kills it).<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,<br>
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn<br>
Handelsregister: Amtsgericht München HRB 153243<br>
Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill,<br>
Eric Shander<br>
_______________________________________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
</font></span></blockquote></div><br></div>