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