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

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

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-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(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