<div dir="auto"><div>It could be interesting to have the possibility to deactivate TTL (for instance by setting a negative value, without any change in the existing API for that) but for the time being we could have the workaround of setting an arbitrary high value, no?</div><div dir="auto"><br></div><div dir="auto">Concerning the time range, at some point I was using "fromEarliest: true", " order: desc" and "limit:1" ... It seems that it could also be used here.</div><div dir="auto"><br></div><div dir="auto">Joel</div><div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Le 28 mars 2017 08:18, "John Sanda" <<a href="mailto:jsanda@redhat.com">jsanda@redhat.com</a>> a écrit :<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">My first thought was a string metric where data points are the servers that get discovered. There are a couple things though that I do not like about this. First, all data point queries in hawkular-metrics have a date range. Having to use a date range here seems a bit awkward. Secondly all data points in hawkular-metrics expire. These does not seem like data that we would want to expire.<div class="elided-text"><div><br><div><blockquote type="cite"><div>On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <<a href="mailto:jshaughn@redhat.com" target="_blank">jshaughn@redhat.com</a>> wrote:</div><br class="m_-2622454687797832344Apple-interchange-newline"><div>
<div bgcolor="#FFFFFF" text="#000000">
<br>
i was thinking, perhaps it's not even necessary to involve inventory
to know if the server was reported or not. We define metrics, like
avail, for these root types, I think. At startup if the metric
existed perhaps you could assume it was already reported, otherwise
you could send a "new server" event. Would that approach fly or be
easier?<br>
<br>
<div class="m_-2622454687797832344moz-cite-prefix">On 3/27/2017 12:40 PM, Joel Takvorian
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">For point 1., we can probably use some functions I
wrote in the integration tests, see there: <a href="https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java" target="_blank">https://github.com/<wbr>jotak/hawkular-agent/blob/<wbr>inventory-strings/hawkular-<wbr>agent-itest-util/src/main/<wbr>java/org/hawkular/agent/itest/<wbr>util/ITestHelper.java</a>
<div><br>
</div>
<div>I assume you can build a canonical path? (The same
"canonical path" than in the existing inventory) If so, the
method "<span style="color:rgb(121,93,163);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre-wrap">getBlueprintFromCP" </span>gives
it to you as an Optional blueprint.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 27, 2017 at 5:00 PM, John
Mazzitelli <span dir="ltr"><<a href="mailto:mazz@redhat.com" target="_blank">mazz@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><tl;dr><br>
<br>
Need ideas on how we are to implement the following two
things in the agent:<br>
<br>
1. At startup, agent needs to ask H-Metrics "what top-level
servers have I told you about in an earlier life?"<br>
<br>
2. When a new server is discovered, the agent should send an
event to the server about the new server EXCEPT if the
server isn't really new at all (see 1. above)<br>
<br>
</tl;dr><br>
<br>
<br>
===<br>
<br>
<br>
This post is to open up a discussion on how we want to
implement a new features in the agent.<br>
<br>
Joel is developing a new "inventory in metrics" feature: <a href="https://github.com/hawkular/hawkular-agent/pull/303" rel="noreferrer" target="_blank">https://github.com/hawkular/ha<wbr>wkular-agent/pull/303</a><br>
<br>
This means the agent will be storing inventory directly into
Hawkular-Metrics. Because of this, we need to figure out how
to get events sent based on things happening in H-Metric's
inventory so MiQ can do things with it (like put things in
the timeline such as "new server discovered" or "new WAR was
deployed").<br>
<br>
Jay looked at the code and the only thing that would be
"missing" after this move of inventory into metrics is an
event triggered when a new server is added to inventory.
(When a new deployment is added, or a deployment is removed,
the server is looking at command responses and generating
events from that - so we don't lose anything by moving
inventory into metrics).<br>
<br>
By "new server", what we mean is a new resource that has no
parent resources (i.e. a "root resource"). This includes
standalone WildFly Servers and domain Host Controllers.<br>
<br>
Right now, the agent starts with a "clean slate" when it
starts up for the first time, or restarts. That means the
agent's in-memory inventory graph is completely empty at
startup - when discovery is run, the agent's internal
inventory graph is filled in. After that, the agent just
keeps the inventory graph up to date as it discovers new
things coming and old things going away.<br>
<br>
We need the agent to know if it already stored its top level
servers into H-Metrics inventory and if it did, not to
generate any "new server event". But if the agent is brand
new, and it never sent any top-level resources to H-Metrics
inventory yet, it should now send a "new server" event to
the server (the agent never sent events like this before).<br>
<br>
So there are two new things (assuming we keep the stuff Joel
is doing - that is, we store inventory into H-Metrics):<br>
<br>
1. At startup, agent needs to ask H-Metrics "what top-level
servers have I told you about in an earlier life?"<br>
<br>
2. When a new server is discovered, the agent should send an
event (whatever this means - probably a REST API call
somewhere) about the new server EXCEPT if the server isn't
really new at all (see 1. above)<br>
<br>
We need to figure out how to implement 1. and 2. So we are
soliciting thoughts on those two subjects.<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">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/mailma<wbr>n/listinfo/hawkular-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_-2622454687797832344mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
hawkular-dev mailing list
<a class="m_-2622454687797832344moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>
<a class="m_-2622454687797832344moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<br>
</div>
______________________________<wbr>_________________<br>hawkular-dev mailing list<br><a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br></div></blockquote></div><br></div></div></div><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></blockquote></div><br></div></div></div>