[openstack-dev] [Metering] Different polling intervals for each pollster
Doug Hellmann
doug.hellmann at dreamhost.com
Wed Nov 7 16:40:53 UTC 2012
On Wed, Nov 7, 2012 at 10:10 AM, Eoghan Glynn <eglynn at redhat.com> wrote:
>
> > 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.
>
> Hi Domus,
>
> For further background see:
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2012-October/001840.html
>
> As explained in that mail, I envisaged the actual periodic task
> interval to be the GCD of the separately configured periods for
> each of the pollsters loaded by the current agent.
>
> Also note the discussion later in the thread on sanity checking
> of the configured pollster intervals.
>
> I'm not sure there is a need for these intervals to be centrally
> managed, rather it could be configured for each compute agent.
> Are you concerned that the intervals would be consistently
> configured across the fleet of the nova compute nodes?
>
Early in the project we decided to assume that deployers could manage
distributing configuration files properly. They already have to do that for
other services, after all, and there are plenty of good tools such as chef,
puppet, and juju that make it easy. I don't see any reason to change that
position and build a control channel into the ceilometer agents to
coordinate the schedule for reporting data.
Doug
>
> Cheers,
> Eoghan
>
> _______________________________________________
> 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/20121107/d9c0b70f/attachment.html>
More information about the OpenStack-dev
mailing list