> b) Assuming there should be one:
>
>* Where should it go? Presumably it needs to be an attribute of
> each sample because as agents leave and join the group, where
> samples are published from can change.is this just for debugging
> purposes or auditing? from an audit standpoint, w
On Wed, Aug 20 2014, Chris Dent wrote:
> a) Am I right that no indicator is there?
Yes.
> b) Assuming there should be one:
>
>* Where should it go? Presumably it needs to be an attribute of
> each sample because as agents leave and join the group, where
> samples are published from
> One of the outcomes from Juno will be horizontal scalability in the
> central agent and alarm evaluator via partitioning[1]. The compute
> agent will get the same capability if you choose to use it, but it
> doesn't make quite as much sense.
>
> I haven't investigated the alarm evaluator side
On Thu, 21 Aug 2014, Nejc Saje wrote:
More riffing: we are moving away from per-sample specific data with Gnocchi.
I don't think we should store this per-sample, since the user doesn't
actually care about which agent the sample came from. The user cares about
which *resource* it came from.
I
On 08/20/2014 09:25 PM, Chris Dent wrote:
On Wed, 20 Aug 2014, gordon chung wrote:
disclaimer: i'm just riffing and the following might be nonsense.
/me is a huge fan of riffing
i guess also to extend your question about agents leaving/joining. i'd
expect there is some volatility to the a
On Wed, 20 Aug 2014, gordon chung wrote:
disclaimer: i'm just riffing and the following might be nonsense.
/me is a huge fan of riffing
i guess also to extend your question about agents leaving/joining. i'd
expect there is some volatility to the agents where an agent may or
may not exist at
> a) Am I right that no indicator is there?
>
> b) Assuming there should be one:
>
> * Where should it go? Presumably it needs to be an attribute of
> each sample because as agents leave and join the group, where
> samples are published from can change.
>
> * How should it be named? The never-en
One of the outcomes from Juno will be horizontal scalability in the
central agent and alarm evaluator via partitioning[1]. The compute
agent will get the same capability if you choose to use it, but it
doesn't make quite as much sense.
I haven't investigated the alarm evaluator side closely yet,
