<br><br><div class="gmail_quote">On Mon, Jan 7, 2013 at 10:19 AM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> Hi, Doug<br>
> As a follow--up with you on the counter frequency discussion, I<br>
> create a wiki page at<br>
> <a href="http://wiki.openstack.org/Ceilometer/blueprints/publisher-counters-frequency" target="_blank">http://wiki.openstack.org/Ceilometer/blueprints/publisher-counters-frequency</a><br>
> . Please have a look on it.<br>
<br>
</div>Some initial thoughts ...<br>
<br>
"The pollster will decide the polling interval based on the GCD<br>
of interval requirement for all of it's counters."<br>
<br>
Would it make sense to factor out from the pollsters this common<br>
logic to calculate the period GCD?<br>
<br>
Also, should we constrain the possible periods to avoid lots of<br>
irregularity (e.g. just allow 1s, 10s, 60s & multiples thereof),<br>
or make it completely free form?<br></blockquote><div><br></div><div>We need to specify a minimum. I'm not sure whether we need to be more strict than that, though. Did you have an example of an issue that might come up if we allow arbitrary values? We should also be clear that we're ensuring a minimum interval, not an absolute rate, for the data. We can't be sure how long it will take to collect a given piece of data, and if there is a long list of counters even the publishing may get in the way of delivering as quickly as is requested.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"... the compute/central service will create a timer for each<br>
pollster based on it's polling interval"<br>
<br>
Do we need a separate timer for each pollster, even when the periods<br>
are common?<br>
<br>
"A interval transformer provided to support different<br>
interval. Considering followed counters sequence as "c0, c1, c2,<br>
c3 ..." for resource_1 and c3 happens "interval time" after c0."<br>
<br>
Is the implicatyion here that *all* counters associated with a<br>
pollster are calculated on the most granular interval, then the<br>
more coarse-grained values are eventually discarded in the<br>
transformer chain?<br>
<br>
That would be fine if only a single measurement (e.g. call out<br>
to a public API service or hypervisor daemon) is required for<br>
all the pollster's counters. But if multiple measurements are<br>
required, would it make sense to avoid the measure-and-discard<br>
pattern?<br></blockquote><div><br></div><div>Yes, we shouldn't be collecting data we know we aren't going to use.</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Eoghan<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>