<div dir="ltr">Maybe the longer-term solution would be a taggable key-value store? Either generic or dedicated...</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 28, 2017 at 3:04 PM, Michael Burman <span dir="ltr"><<a href="mailto:miburman@redhat.com" target="_blank">miburman@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think Cassandra supports that. If there's a table TTL, one needs<br>
to set a TTL to override the default expiry.<br>
<br>
- Micke<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 03/28/2017 03:34 PM, John Mazzitelli wrote:<br>
> how about make a value -2 meaning "no TTL at all - ignore even the table TTL"<br>
><br>
> ----- Original Message -----<br>
>> Hi,<br>
>><br>
>> If you use TTL -1 in current Hawkular-Metrics, we will write without<br>
>> setting TTL information. At that point the table TTL will be used (if<br>
>> such is set).<br>
>><br>
>> - Micke<br>
>><br>
>><br>
>> On 03/28/2017 11:36 AM, Joel Takvorian wrote:<br>
>>> It could be interesting to have the possibility to deactivate TTL (for<br>
>>> instance by setting a negative value, without any change in the<br>
>>> existing API for that) but for the time being we could have the<br>
>>> workaround of setting an arbitrary high value, no?<br>
>>><br>
>>> Concerning the time range, at some point I was using "fromEarliest:<br>
>>> true", " order: desc" and "limit:1" ... It seems that it could also be<br>
>>> used here.<br>
>>><br>
>>> Joel<br>
>>><br>
>>><br>
>>> Le 28 mars 2017 08:18, "John Sanda" <<a href="mailto:jsanda@redhat.com">jsanda@redhat.com</a><br>
>>> <mailto:<a href="mailto:jsanda@redhat.com">jsanda@redhat.com</a>>> a écrit :<br>
>>><br>
>>> My first thought was a string metric where data points are the<br>
>>> servers that get discovered. There are a couple things though that<br>
>>> I do not like about this. First, all data point queries in<br>
>>> hawkular-metrics have a date range. Having to use a date range<br>
>>> here seems a bit awkward. Secondly all data points in<br>
>>> hawkular-metrics expire. These does not seem like data that we<br>
>>> would want to expire.<br>
>>><br>
>>>> On Mar 27, 2017, at 5:02 PM, Jay Shaughnessy <<a href="mailto:jshaughn@redhat.com">jshaughn@redhat.com</a><br>
>>>> <mailto:<a href="mailto:jshaughn@redhat.com">jshaughn@redhat.com</a>>> wrote:<br>
>>>><br>
>>>><br>
>>>> i was thinking, perhaps it's not even necessary to involve<br>
>>>> inventory to know if the server was reported or not. We define<br>
>>>> metrics, like avail, for these root types, I think. At startup<br>
>>>> if the metric existed perhaps you could assume it was already<br>
>>>> reported, otherwise you could send a "new server" event. Would<br>
>>>> that approach fly or be easier?<br>
>>>><br>
>>>> On 3/27/2017 12:40 PM, Joel Takvorian wrote:<br>
>>>>> For point 1., we can probably use some functions I wrote in the<br>
>>>>> integration tests, see there:<br>
>>>>> <a href="https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java" rel="noreferrer" target="_blank">https://github.com/jotak/<wbr>hawkular-agent/blob/inventory-<wbr>strings/hawkular-agent-itest-<wbr>util/src/main/java/org/<wbr>hawkular/agent/itest/util/<wbr>ITestHelper.java</a><br>
>>>>> <<a href="https://github.com/jotak/hawkular-agent/blob/inventory-strings/hawkular-agent-itest-util/src/main/java/org/hawkular/agent/itest/util/ITestHelper.java" rel="noreferrer" target="_blank">https://github.com/jotak/<wbr>hawkular-agent/blob/inventory-<wbr>strings/hawkular-agent-itest-<wbr>util/src/main/java/org/<wbr>hawkular/agent/itest/util/<wbr>ITestHelper.java</a>><br>
>>>>><br>
>>>>><br>
>>>>> I assume you can build a canonical path? (The same "canonical<br>
>>>>> path" than in the existing inventory) If so, the method<br>
>>>>> "getBlueprintFromCP" gives it to you as an Optional blueprint.<br>
>>>>><br>
>>>>> On Mon, Mar 27, 2017 at 5:00 PM, John Mazzitelli<br>
>>>>> <<a href="mailto:mazz@redhat.com">mazz@redhat.com</a> <mailto:<a href="mailto:mazz@redhat.com">mazz@redhat.com</a>>> wrote:<br>
>>>>><br>
>>>>> <tl;dr><br>
>>>>><br>
>>>>> Need ideas on how we are to implement the following two<br>
>>>>> things in the agent:<br>
>>>>><br>
>>>>> 1. At startup, agent needs to ask H-Metrics "what top-level<br>
>>>>> servers have I told you about in an earlier life?"<br>
>>>>><br>
>>>>> 2. When a new server is discovered, the agent should send an<br>
>>>>> event to the server about the new server EXCEPT if the<br>
>>>>> server isn't really new at all (see 1. above)<br>
>>>>><br>
>>>>> </tl;dr><br>
>>>>><br>
>>>>><br>
>>>>> ===<br>
>>>>><br>
>>>>><br>
>>>>> This post is to open up a discussion on how we want to<br>
>>>>> implement a new features in the agent.<br>
>>>>><br>
>>>>> Joel is developing a new "inventory in metrics" feature:<br>
>>>>> <a href="https://github.com/hawkular/hawkular-agent/pull/303" rel="noreferrer" target="_blank">https://github.com/hawkular/<wbr>hawkular-agent/pull/303</a><br>
>>>>> <<a href="https://github.com/hawkular/hawkular-agent/pull/303" rel="noreferrer" target="_blank">https://github.com/hawkular/<wbr>hawkular-agent/pull/303</a>><br>
>>>>><br>
>>>>> This means the agent will be storing inventory directly into<br>
>>>>> Hawkular-Metrics. Because of this, we need to figure out how<br>
>>>>> to get events sent based on things happening in H-Metric's<br>
>>>>> inventory so MiQ can do things with it (like put things in<br>
>>>>> the timeline such as "new server discovered" or "new WAR was<br>
>>>>> deployed").<br>
>>>>><br>
>>>>> Jay looked at the code and the only thing that would be<br>
>>>>> "missing" after this move of inventory into metrics is an<br>
>>>>> event triggered when a new server is added to inventory.<br>
>>>>> (When a new deployment is added, or a deployment is removed,<br>
>>>>> the server is looking at command responses and generating<br>
>>>>> events from that - so we don't lose anything by moving<br>
>>>>> inventory into metrics).<br>
>>>>><br>
>>>>> By "new server", what we mean is a new resource that has no<br>
>>>>> parent resources (i.e. a "root resource"). This includes<br>
>>>>> standalone WildFly Servers and domain Host Controllers.<br>
>>>>><br>
>>>>> Right now, the agent starts with a "clean slate" when it<br>
>>>>> starts up for the first time, or restarts. That means the<br>
>>>>> agent's in-memory inventory graph is completely empty at<br>
>>>>> startup - when discovery is run, the agent's internal<br>
>>>>> inventory graph is filled in. After that, the agent just<br>
>>>>> keeps the inventory graph up to date as it discovers new<br>
>>>>> things coming and old things going away.<br>
>>>>><br>
>>>>> We need the agent to know if it already stored its top level<br>
>>>>> servers into H-Metrics inventory and if it did, not to<br>
>>>>> generate any "new server event". But if the agent is brand<br>
>>>>> new, and it never sent any top-level resources to H-Metrics<br>
>>>>> inventory yet, it should now send a "new server" event to<br>
>>>>> the server (the agent never sent events like this before).<br>
>>>>><br>
>>>>> So there are two new things (assuming we keep the stuff Joel<br>
>>>>> is doing - that is, we store inventory into H-Metrics):<br>
>>>>><br>
>>>>> 1. At startup, agent needs to ask H-Metrics "what top-level<br>
>>>>> servers have I told you about in an earlier life?"<br>
>>>>><br>
>>>>> 2. When a new server is discovered, the agent should send an<br>
>>>>> event (whatever this means - probably a REST API call<br>
>>>>> somewhere) about the new server EXCEPT if the server isn't<br>
>>>>> really new at all (see 1. above)<br>
>>>>><br>
>>>>> We need to figure out how to implement 1. and 2. So we are<br>
>>>>> soliciting thoughts on those two subjects.<br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> hawkular-dev mailing list<br>
>>>>> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
>>>>> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.<wbr>jboss.org</a>><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
>>>>> <<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> hawkular-dev mailing list<br>
>>>>> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.<wbr>jboss.org</a>><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
>>>>> <<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>><br>
>>>> ______________________________<wbr>_________________ hawkular-dev<br>
>>>> mailing list <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
>>>> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.<wbr>jboss.org</a>><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
>>>> <<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>><br>
>>> ______________________________<wbr>_________________ hawkular-dev<br>
>>> mailing list <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
>>> <mailto:<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.<wbr>jboss.org</a>><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
>>> <<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> hawkular-dev mailing list<br>
>>> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
>> ______________________________<wbr>_________________<br>
>> hawkular-dev mailing list<br>
>> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
>><br>
> ______________________________<wbr>_________________<br>
> hawkular-dev mailing list<br>
> <a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
</div></div></blockquote></div><br></div>