Re: [Hawkular-dev] agent "new server" event

I don't think Cassandra supports that. If there's a table TTL, one needs to set a TTL to override the default expiry.

- Micke On 03/28/2017 03:34 PM, John Mazzitelli wrote: > 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(a)redhat.com >>> <mailto:jsanda@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(a)redhat.com >>>> <mailto:jshaughn@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-a... >>>>> <https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-a... >>>>> >>>>> >>>>> 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(a)redhat.com <mailto:mazz@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(a)lists.jboss.org >>>>> <mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org >>>> <mailto:hawkular-dev@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(a)lists.jboss.org >>> <mailto:hawkular-dev@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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev