Open Stack

On Fri, Oct 26 2012, Eoghan Glynn wrote:

Hi Eoghan,

> So for example the compute.libvirt.DiskIOPollster would provide a
> transformer to map the raw disk stats reported by libvirt into
> DiskWriteOps, DiskWriteBytes, DiskReadOps & DiskReadBytes metric
> datapoints for CW, also indicating that this should be published
> very minute. This CWPublisher would handle batching these data
> as a single PutMetricData call.
>
> The DiskIOPollster would also provide a second Transformer to
> mediate between the raw stats format and the ceilo Counter
> representation for metering.  Additionally, this second Publisher
> could be configured with a longer period (as befits metering data
> likely to be consumed by a billing engine).

I don't think it's up to the Pollster to provide Transformers. If we go
on that road, I'm afraid it complicates a lot the Pollster writing.

Why wouldn't each publisher be in charge to convert the Counters yielded
by the Pollsters using whatever their own Transformer(s)?

> Now the frequency aspect is a bit awkward. For notifications,
> the frequency of the "exists" style of usage audit is out of our
> hands, depending usually on the configuration of the emitter
> (e.g. the nova instance_usage_audit_period config). Whereas ceilo
> config direct controls only the frequency of polling. So one idea 
> would be for a publisher's frequency only to impact on the periods
> under ceilo control - i.e. we'd accept and publish notifications
> whenever we get them, whereas the polling cycle would be determined
> by the greatest common divisor of all the configured publisher
> periods for each set of related pollsters (the config would probably
> have to be restricted so to ensure a sane GCD). 

That makes sense. Basically, your polling frequence should be
automatically computed to be the min() of the frequency requested by all
enabled Publishers.

For notifications, the code rounting Counter to Publishers may/should
filter out the Counters if they are likely to be emitted wrt with what a
Publisher asked for.

-- 
Julien Danjou
# Free Software hacker & freelance
# http://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121026/8aeef062/attachment.pgp>