Open Stack

On Fri, Oct 26, 2012 at 10:19 AM, Eoghan Glynn <eglynn at redhat.com> wrote:

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

OK, that makes sense.

Doug


>
> 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
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121026/c5e8c2c9/attachment.html>