On Tue, Mar 28, 2017 at 3:04 PM, Michael Burman <miburman@redhat.com> wrote:

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@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@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@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@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@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@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@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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev