<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 4, 2016 at 11:20 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>
Right now we identify "agents" via their feed-id.<br>
An instrumented wildfly comes online, registers<br>
its feed with the server, sends its resource discovery<br>
and later metrics with the feed id.<br>
Over its lifecycle, the server may be stopped and re-started<br>
several times.<br>
<br>
This is great in the classical use case with installations<br>
on tin or VMs.<br>
<br>
In container-land especially with systems like Kubernetes,<br>
containers are started once and after they have died for<br>
whatever reason they are not restarted again.<br>
So the id of an individual container is less and less interesting.<br>
The interesting part is the overall app, that contains of many<br>
containers linked together with several of them representing<br>
an individual service of the app.<br>
<br>
So basically we would rather need to record the app and other<br>
metadata for identifying individual parts of the app (e.g. the web<br>
servers or the data bases) and then get pointers to individual<br>
stuff.<br>
The feed would not need to survive for too long, but some of<br>
its collected data perhaps. And then e.g. the discovery of resources<br>
in a new container of the exact same type as before should be sort<br>
of a no-op, as we know this already. Could we short-circuit that<br>
by storing the docker-image-hash (or similar) and once we see this<br>
known one abort the discovery?<br>
<br>
Another aspect is certainly that we want to keep (some) historic<br>
records of the died container - e.g. some metrics and the point<br>
when it died. Suppose k8s kills a container and spins a new one<br>
up (same image) on a different node, then logically it is a continuation<br>
of the first one, but in a different place (but they have different feed<br>
ids)<br>
<br>
Now a more drastic scenario: As orchestration systems like k8s or<br>
Docker-Swarm have their own registries, that can be queried : do we need<br>
a<br>
hawkular-inventory for this at all?<br></blockquote><div><br></div><div>My gut feeling: no or not now...</div><div>We may want/need it if we ever wanted to keep info about what's inside the containers (such as which war are in that EAP running in that container), but the need hasn't been expressed so far.</div><div><br></div><div>Thomas</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
( We still need it for the non-OpenShift/K8s/Docker-Swarm envs )<br>
<span class="HOEnZb"><font color="#888888"><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>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br>
<br>
</font></span></blockquote></div><br></div></div>