Open Stack

> > 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.

That was just poorly expressed in my initial mail. The intent was
more like:

 "the DiskIOPollster could also be associated with a second Transformer
  via configuration ..."
 
> Why wouldn't each publisher be in charge to convert the Counters yielded
> by the Pollsters using whatever their own Transformer(s)?

Yes, I think we may be ad idem on that point.

The idea was to split the publisher and transformer concerns, as
there are likely to be far fewer of the former than the latter.

For example, we might have a single CloudWatchPublisher that
knows how to call PutMetricData with any metric datum, and also
multiple CloudWatchTransformers who each know how to construct a
particular set of metrics from some domain-specific raw data
(e.g. the disk stats returned by libvirt).

Cheers,
Eoghan

 
> > 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>