[Hawkular-dev] agent "new server" event

Jay Shaughnessy jshaughn at redhat.com
Mon Mar 27 17:02:15 EDT 2017


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?

On 3/27/2017 12:40 PM, Joel Takvorian wrote:
> For point 1., we can probably use some functions I wrote in the 
> integration tests, see there: 
> https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java 
>
>
> I assume you can build a canonical path? (The same "canonical path" 
> than in the existing inventory) If so, the method "getBlueprintFromCP" 
> gives it to you as an Optional blueprint.
>
> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli <mazz at redhat.com 
> <mailto:mazz at redhat.com>> wrote:
>
>     <tl;dr>
>
>     Need ideas on how we are to implement the following two things in
>     the agent:
>
>     1. At startup, agent needs to ask H-Metrics "what top-level
>     servers have I told you about in an earlier life?"
>
>     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)
>
>     </tl;dr>
>
>
>     ===
>
>
>     This post is to open up a discussion on how we want to implement a
>     new features in the agent.
>
>     Joel is developing a new "inventory in metrics" feature:
>     https://github.com/hawkular/hawkular-agent/pull/303
>     <https://github.com/hawkular/hawkular-agent/pull/303>
>
>     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").
>
>     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).
>
>     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.
>
>     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.
>
>     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).
>
>     So there are two new things (assuming we keep the stuff Joel is
>     doing - that is, we store inventory into H-Metrics):
>
>     1. At startup, agent needs to ask H-Metrics "what top-level
>     servers have I told you about in an earlier life?"
>
>     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)
>
>     We need to figure out how to implement 1. and 2. So we are
>     soliciting thoughts on those two subjects.
>     _______________________________________________
>     hawkular-dev mailing list
>     hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hawkular-dev
>     <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20170327/8b14e6c5/attachment.html 


More information about the hawkular-dev mailing list