<div>Hi, Chris,</div><div><br></div><div>In current, ceilometer load pollsters by agent namespace, So do you mean you want load pollsters one by one through <span style="line-height: 1.5;">their name(maybe defined in pipeline.yaml)?</span></div><div><br></div><div>If loading all pollsters in one time do not cost much, I think your change is bit unnecessary. </div><div>But if it does cost much, your change is meaningful.</div><div><br></div><div>BTW,  I like the idea "<span style="line-height: 1.5;">Separate polling and publishing/transforming into separate</span></div><div><span style="line-height: 1.5;">   workers/processes.</span>"</div><div><div style="color:#909090;font-family:Arial Narrow;font-size:12px">------------------</div><div style="font-size:14px;font-family:Verdana;color:#000;">Luo Gangyi<div><div>luogangyi@cmss.chinamobile.com</div></div></div></div><div> </div><div><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b> "Chris Dent";<chdent@redhat.com>;</div><div><b>Date: </b> Mon, Jun 8, 2015 09:04 PM</div><div><b>To: </b> "openstack-operators"<openstack-operators@lists.openstack.org>; "OpenStack-dev"<OpenStack-dev@lists.openstack.org>; <wbr></div><div></div><div><b>Subject: </b> [openstack-dev] [ceilometer] polling agent configuration speculation</div></div><div><br></div><br>(Posting to the mailing list rather than writing a spec or making<br>code because I think it is important to get some input and feedback<br>before going off on something wild. Below I'm talking about<br>speculative plans and seeking feedback, not reporting decisions<br>about the future. Some of this discussion is intentionally naive<br>about how things are because that's not really relevant, what's<br>relevant is how things should be or could be.<br><br>tl;dr: I want to make the configuration of the pollsters more explicit<br>and not conflate and overlap the entry_points.txt and pipeline.yaml<br>in confusing and inefficient ways.<br><br>* entry_points.txt should define what measurements are possible, not<br>   what measurements are loaded<br>* something new should define what measurements are loaded and<br>   polled (and their intervals) (sources in pipeline.yaml speak)<br>* pipeline.yaml should define transformations and publishers<br><br>Would people like something like this?)<br><br>The longer version:<br><br>Several of the outcomes of the Liberty Design Summit were related to<br>making changes to the agents which gather or hear measurements and<br>events. Some of these changes have pending specs:<br><br>* Ceilometer Collection Agents Split<br>   https://review.openstack.org/#/c/186964/<br><br>   Splitting the collection agents into their own repo to allow<br>   use and evolution separate from the rest of Ceilometer.<br><br>* Adding Meta-Data Caching Spec<br>   https://review.openstack.org/#/c/185084/<br><br>   Adding metadata caching to the compute agent so the Nova-API is<br>   less assaulted than it currently is.<br><br>* Declarative notification handling<br>   https://review.openstack.org/#/c/178399/<br><br>   Be able to hear and transform a notification to an event without<br>   having to write code.<br><br>Reviewing these and other specs and doing some review of the code<br>points out that we have an opportunity to make some architectural and<br>user interface improvements (while still maintain existing<br>functionality). For example:<br><br>The current ceilometer polling agent has an interesting start up<br>process:<br><br>1 It determines which namespaces it is operating in ('compute',<br>   'central', 'ipmi').<br>2 Using entry_points defined in setup.cfg it initializes all the<br>   polling extensions and all the discovery extensions (independent<br>   of sources defined in pipeline.yaml)<br>3 Every source in pipeline.yaml is given a list of pollsters that<br>   match the meters defined by the source, creating long running<br>   tasks to do the polling.<br>4 Each task does resource discovery and partitioning coordination.<br>5 measurements/samples are gathered and are transformed and published<br>   according the sink rules in pipeline.yaml<br><br>A couple things about this seem less than ideal:<br><br>* 2 means we load redundant stuff unless we edit entry_points.txt.<br>   We do not want to encourage this sort of behavior. entry_points is<br>   not configuration[1]. We should configure elsewhere to declare "I<br>   care about things X (including the option of "all things")" and<br>   then load the tools to do so, on demand.<br><br>* Two things are happening in the same context in step 5 and that<br>   seems quite limiting with regard to opportunities for effective<br>   maintenance and optimizing.<br><br>My intuition (which often needs to sanity checked, thus my posting<br>here) tells me there are some things we could change:<br><br>* Separate polling and publishing/transforming into separate<br>   workers/processes.<br><br>* Extract the definition of sources to be polled from pipeline.yaml<br>   to its own file and use that to be the authority of which<br>   extensions are loaded for polling and discovery.<br><br>What do people think?<br><br>[1] This is really the core of my concern and the main part I want<br>to see change.<br>-- <br>Chris Dent tw:@anticdent freenode:cdent<br>https://tank.peermore.com/tanks/cdent<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div>