[openstack-dev] [Metering] Different polling intervals for each pollster

Vincenzo Di Somma vincenzo.di.somma at canonical.com
Thu Nov 15 15:47:37 UTC 2012


Hello Nick, I sent the patch more to continue with the discussion than
to propose actual code to land, but if you think it's worth to move the
discussion to gerrit I'm happy to propose a branch. :)

		vds

On 11/15/2012 03:59 PM, Nicolas Barcet wrote:
> Hello Vincenzo,
> 
> Thanks for sharing your patch, but why not directly put it up for review
> on gerrit.  You're more likely to be able to track comments this way....
> 
> Thanks,
> Nick
> 
> 
> On Thu, Nov 15, 2012 at 2:50 PM, Vincenzo Di Somma
> <vincenzo.di.somma at canonical.com
> <mailto:vincenzo.di.somma at canonical.com>> wrote:
> 
>     Hello, we started to work on this, but before we go too far we'd like to
>     check if that's the right approach, I'm attaching a small patch.
>     Thanks,
>                     vds
> 
>     On 11/07/2012 02:29 PM, Domas Monkus wrote:
>     > Hello,
>     > I have found the following wish-list item in the ceilometer project:
>     > https://bugs.launchpad.net/ceilometer/+bug/1010037
>     >
>     > I have read the associated email thread [1] and launchpad
>     blueprint [2],
>     > however, the task still seems in need of further discussions. To
>     be more
>     > exact, there are a few things that are still unclear:
>     >
>     > 1. How should pollster-specific polling intervals be specified? The
>     > blueprint mentions that publishers (I assume it means collectors)
>     should
>     > specify the intervals, however I don't think that a communication
>     > channel between the collector and the central agent running the
>     > pollsters is in place.
>     >
>     > 2. Should pollsters be able to specify a polling interval (perhaps an
>     > inherited default) to the central agent?
>     >
>     > 3. If other ways of setting the polling intervals are probably
>     possible
>     > (e.g. the config file), should there be a hierarchy specified of which
>     > setting override which ones?
>     >
>     > 4. Should the current periodic_interval configuration value be
>     used as a
>     > safe fall back for pollsters without explicitly defined values?
>     >
>     > 5. What is the granularity of polling intervals? Seconds?
>     >
>     >
>     > And finally an implementation idea:
>     > I do not think that having separate periodic tasks for each
>     pollster is
>     > the best solution for this problem. Assuming a second granularity for
>     > polling intervals, the central agent manager can maintain a map of
>     > pollsters and their intervals. As long as the manager is called
>     with an
>     > interval that is a GCD of its pollster intervals, it can basically
>     > calculate how often each pollster should be queried.
>     >
>     > Domas Monkus
>     >
>     > [1] https://lists.launchpad.net/openstack/msg12916.html
>     > [2]
>     >
>     https://blueprints.launchpad.net/ceilometer/+spec/publisher-counters-frequency
>     >
>     >
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto: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
>     <mailto: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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121115/2213bed0/attachment.pgp>


More information about the OpenStack-dev mailing list