On Mon, 2014-01-13 at 13:39 +0400, Nadya Privalova wrote: > Jay, > > > Thanks for comments! > > The question you raised was discussed several times within Ceilometer > team but as I understand there is no official resolution yet. > > I agree with you that statistics' collection is the main Ceilometer's > goal. But at the same time there should be a way to visualize the > result of Ceilometer's work. > > My opinion is that the current set of data queries (get samples, get > statistics) is the minimum set and it's ok to keep it as a part of > Ceilometer's functionality. We need it at least for UI.
Yes, I've seen the (excellent) wireframes that Jarda and others have been working on, and I can certainly see where the feature request comes from. > So, my proposal is to make this existing queries faster. Looks like > our vision are the same :) Certainly :) > Pre-calculate when? :) During processing of samples, or during > some > periodic job? > > > It should be a periodic job, right. I'm actually not so sure. If you spread the work of updating the aggregate into the (multi-processed) collectors, then updating the aggregates become less resource-intensive. It's the same idea behind putting a SQL trigger on a table in an RDBMS that updates a rolling aggregate. Doing the update work one little piece at a time can be more efficient than doing a large update on a periodic job -- particularly when, as is the case here, the long-running periodic update job would need to take locks on the base fact tables. > > The term "aggregate" really just means a generic grouping or > summarization. If you are looking for a term that represents > the > rules/heuristics for maintaining rolling calculations, perhaps > the term > "report" is better? > > > Hmm, I think that 'aggregate' is ok. In "my terminology" an aggregate > is a ready set of statistics for concrete meter, period and query. > Anyway, will think about it. Sure, not a big deal. Was just throwing out ideas, really. "Aggregate" is fine. Best, -jay _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
