Open Stack

Isn't this the same topic as the one on Monday that Annie setup?

https://lists.launchpad.net/openstack/msg17802.html

Lets not redo the same logic in two places.

-A

On 26/10/12 11:58 -0400, Eoghan Glynn wrote:
>
>
>> I agree, pollsters and publishers shouldn't have to know about each
>> other. We should try to make Counter() objects the common data
>> object used on both sides of the transformation. Notification
>> listeners and pollsters should emit Counter instances and Publishers
>> should take Counters and send out formatted data. If the current
>> definition of a Counter doesn't support all of our use cases, we
>> should change it.
>
>Well, what I was trying to avoid there was bloating up the Counter
>with fields that are only of interest to a subset of publishers.
>So the idea was to just do a direct transformation from the raw data
>to the representation most appropriate for the associated publisher.
>It seemed to introduce less "impedance" to just go directly from
>raw data to say a type like boto.ec2.cloudwatch.datapoint.Datapoint,
>instead of using the ceilo Counter type as an intermediate step.
>
>The reason for avoiding building that logic into the publisher is
>to split off knowledge (say in the cloudwatch case) of the metric
>naming, units etc. specific to each type of raw data produced by a
>pollster or notification handler (so for ex. a CWPublisher wouldn't
>need to be concerned with the differences between CPU/network/disk/
>whatever stats).
>
>
>> I want to, eventually, change the auditing stuff from of the other
>> projects because it doesn't support our use cases. I haven't had a
>> chance to study what use cases it really does support to ensure that
>> Ceilometer would meet those needs in the future, so for now, we can
>> mostly ignore them. Quantum didn't have anything like that, so we
>> added it in a way that works for us. Nova and Cinder share the same
>> old implementation, but the polling the Ceilometer agent does makes
>> up for the sparse event generation.
>
>Cool enough.
>
>
>> Do we need to protect against having the polling performed too
>> frequently and consuming too many resources on the server?
>
>So the idea is to mitigate this by sharing polling cycles where possible.
>
>Say the metering publisher needs to sample every 10 minutes, whereas a
>metrics publisher needs a more fine-grain, say every 2 minutes. In that
>case, the yield from every fifth polling cycle will be shared and published
>by both.
>
>Cheers,
>Eoghan
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev