Open Stack

On 28/04/17 09:19 AM, Julien Danjou wrote:
> That's not what I meant. You can have the same mechanism as currently,
> but then you compute the sacks of all metrics and you
> itertools.groupby() per sack on them before locking the sack and
> expunging them.

yeah, we should do that. i'll add that as a patch.

>
>> > refresh is currently disabled by default so i think we're ok.
> Well you mean it's disabled by default _in the CLI_, not in the API
> right?

refresh i believe is always disabled by default regardless of what 
interface you're using.

>
>> > what's the timeout for? timeout api's attempt to aggregate metric? i
>> > think it's a bad experience if we add any timeout since i assume it will
>> > still return what it can return and then the results become somewhat
>> > ambiguous.
> No, I meant timeout for grabbing the sack's lock. You wouldn't return a
> 2xx but a 5xx stating the API is unable to compute stuff right now, so
> try again without refresh or something.

in the case of cross-metric aggregations, this is a timeout for entire 
request or per metric timeout? i think it's going to get quite chaotic 
in the multiple metric (multiple sacks) refresh. :(

i'm hoping not to have a timeout because i imagine there will be 
scenarios where we block trying to lock sack, and when we finally get 
sack lock, we find there is no work for us. this means we just added x 
seconds to response to for no reason.

-- 
gord