<br><br><div class="gmail_quote">On Fri, Oct 26, 2012 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>
> > The DiskIOPollster would also provide a second Transformer to<br>
> > mediate between the raw stats format and the ceilo Counter<br>
> > representation for metering.  Additionally, this second Publisher<br>
> > could be configured with a longer period (as befits metering data<br>
> > likely to be consumed by a billing engine).<br>
><br>
> I don't think it's up to the Pollster to provide Transformers. If we go<br>
> on that road, I'm afraid it complicates a lot the Pollster writing.<br>
<br>
</div>That was just poorly expressed in my initial mail. The intent was<br>
more like:<br>
<br>
 "the DiskIOPollster could also be associated with a second Transformer<br>
  via configuration ..."<br>
<div class="im"><br>
> Why wouldn't each publisher be in charge to convert the Counters yielded<br>
> by the Pollsters using whatever their own Transformer(s)?<br>
<br>
</div>Yes, I think we may be ad idem on that point.<br>
<br>
The idea was to split the publisher and transformer concerns, as<br>
there are likely to be far fewer of the former than the latter.<br>
<br>
For example, we might have a single CloudWatchPublisher that<br>
knows how to call PutMetricData with any metric datum, and also<br>
multiple CloudWatchTransformers who each know how to construct a<br>
particular set of metrics from some domain-specific raw data<br>
(e.g. the disk stats returned by libvirt).<br></blockquote><div><br></div><div>OK, that makes sense.</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="im HOEnZb"><br>
<br>
> > Now the frequency aspect is a bit awkward. For notifications,<br>
> > the frequency of the "exists" style of usage audit is out of our<br>
> > hands, depending usually on the configuration of the emitter<br>
> > (e.g. the nova instance_usage_audit_period config). Whereas ceilo<br>
> > config direct controls only the frequency of polling. So one idea<br>
> > would be for a publisher's frequency only to impact on the periods<br>
> > under ceilo control - i.e. we'd accept and publish notifications<br>
> > whenever we get them, whereas the polling cycle would be determined<br>
> > by the greatest common divisor of all the configured publisher<br>
> > periods for each set of related pollsters (the config would<br>
> > probably<br>
> > have to be restricted so to ensure a sane GCD).<br>
><br>
> That makes sense. Basically, your polling frequence should be<br>
> automatically computed to be the min() of the frequency requested by<br>
> all<br>
> enabled Publishers.<br>
><br>
> For notifications, the code rounting Counter to Publishers may/should<br>
> filter out the Counters if they are likely to be emitted wrt with<br>
> what a<br>
> Publisher asked for.<br>
><br>
> --<br>
> Julien Danjou<br>
> # Free Software hacker & freelance<br>
> # <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
><br>
<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>