Open Stack

> 
> A couple things about this seem less than ideal:
> 
> * 2 means we load redundant stuff unless we edit entry_points.txt.
> We do not want to encourage this sort of behavior. entry_points is
> not configuration[1]. We should configure elsewhere to declare "I
> care about things X (including the option of "all things")" and
> then load the tools to do so, on demand.
> 
> * Two things are happening in the same context in step 5 and that
> seems quite limiting with regard to opportunities for effective
> maintenance and optimizing.
> 
> My intuition (which often needs to sanity checked, thus my posting
> here) tells me there are some things we could change:
> 
> * Separate polling and publishing/transforming into separate
> workers/processes.
> 
> * Extract the definition of sources to be polled from pipeline.yaml
> to its own file and use that to be the authority of which
> extensions are loaded for polling and discovery.

i still like the idea of splitting polling and processing task.

pros: 
- it moves load off poll agents and onto notificaiton agent
- we essentially get free healthcheck events by doing this

con:
to play devil's advocate. the one down side is that now there's two levels of filtering (something we also ran into for declarative meters.)

in notification agents we first define which exchanges we want to listen to, and then we also define which event_types we want to build off of. similarly, here define what you want to poll, and then in notification agent, you define what you want to build.

so now you need to ensure what you're polling matches up with what you want to build (ie. you're polling the right things to build the data you want or you're not polling stuff you don't intend to poll)... this may or may not be a huge issue but it may be confusing to some.

that said, i don't see this being any different from users configuring notifications in cinder/nova/etc... and matching that configuration to what ceilometer is configured to build.

cheers,
gord 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150609/3ad5eb86/attachment.html>