[Hawkular-dev] agent "new server" event

Tue Mar 28 08:34:55 EDT 2017

how about make a value -2 meaning "no TTL at all - ignore even the table TTL"

----- Original Message -----
> Hi,
> 
> If you use TTL -1 in current Hawkular-Metrics, we will write without
> setting TTL information. At that point the table TTL will be used (if
> such is set).
> 
>    -  Micke
> 
> 
> On 03/28/2017 11:36 AM, Joel Takvorian wrote:
> > 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?
> >
> > 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.
> >
> > Joel
> >
> >
> > Le 28 mars 2017 08:18, "John Sanda" <jsanda at redhat.com
> > <mailto:jsanda at redhat.com>> a écrit :
> >
> >     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.
> >
> >>     On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <jshaughn at redhat.com
> >>     <mailto:jshaughn at redhat.com>> wrote:
> >>
> >>
> >>     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
> >>>     <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 <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
> >>     <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
> >     <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
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>