[openstack-dev] [ceilometer] Pollsters and counters

Jiang, Yunhong yunhong.jiang at intel.com
Thu Jan 17 11:16:38 UTC 2013





> -----Original Message-----

> From: Julien Danjou [mailto:julien at danjou.info]

> Sent: Thursday, January 17, 2013 5:13 PM

> To: Jiang, Yunhong

> Cc: openstack-dev at lists.openstack.org

> Subject: Re: [openstack-dev] [ceilometer] Pollsters and counters

>

> On Thu, Jan 17 2013, Jiang, Yunhong wrote:

>

> > a) as discussed before, the pipeline definition should not be changed in

> > deployment unless expert user. While in deployment, user may want to

> disable

> > some counter specifically.

>

> I don't think we are sure about that. The pipeline definition is also

> going to configure the periodicity of pollsters for example. It's really

> likely that it's going to be modified.

>

> AFAIK the assupmtion that the pipeline is not going to be modified has

> been asserted because it seems that the pipeline is going to be complex

> for publisher like CloudWatch because of the amount of transformers

> needed.



> If this is a problem, this is likely to be hidden in another way, like

> the ability of defining a transformer based on several transformer (some

> sort of macro).

>

> > b) If we really have several publishers (3 or 4, or even more), that means

> > user have to excluded the counters in each pipeline definition and that's

> > not so convenient. After all, pipeline is mostly a per-publisher

> > configuration.

>

> I don't think it's really a problem to disable counters when you have 3

> or 4 publishers. People configuring 3 or 4 publishers will have to know

> what they're doing.


The pipeline for CloudWatch will not be very simple at least in my previous patch series :) But yes that the administrator should be qualified to modify it.



>

> > BTW, I noticed the glance pollster is one counter per pollster while swift

> > pollster is all counters in one pollster. I think we need keep it same for

> > all resource pollster.

>

> Yes, don't worry, we know the current state is not ideal. But it's

> working, that's already a good point. :)



Totally agree that we already have a good point ......



--jyh

>

> --

> Julien Danjou

> -- Free Software hacker & freelance

> -- http://julien.danjou.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130117/b4d62417/attachment.html>


More information about the OpenStack-dev mailing list