[openstack-dev] [ceilometer] using entry_points for configuration considered harmful

Chris Dent chdent at redhat.com
Fri Sep 11 10:31:07 UTC 2015


Several weeks ago I made a little tool call pollman[1] that demonstrates
pollsters plugins that are outside the ceilometer python namespace. I
was going to use it in my portion of a summit talk to show just how
incredibly easy it is to create custom pollsters. After getting the
basics working and testing it out I forgot all about it until reminded
about it in a way that I think demonstrates a fairly significant problem
in the way that ceilometer (and perhaps other OpenStack projects) manage
extensions.

Ceilometer is now frozen for Liberty so I've been doing a lot of
devstack runs to find and fix bugs. And what do I spy with my little
cli but:

     $ ceilometer meter-list
     [...]
     | weather.temperature  | gauge      | C  | 2172797  | pollman | pollman |

     $ ceilometer sample-list -q resource_id=2172797 --limit 1
     [...]
     | 0b667812-586a-11e5-9568-3417ebd4f75d | 2172797     | weather.temperature | gauge | 18.62  | C    | 2015-09-11T09:46:58.571000 |

It's 18.62 C in Newquay today. Good to know.

I have not configured Ceilometer to do this. Pollman set
entry_points on ceilometer months ago and they are being used today.

This is really weird to me. I know why it is happening; it is the
designed in behavior that ceilometer pollsters will activate and run all
available pollster plugins (even when there are not resources available)
but goodness me that's not very explicit.

If I want this to stop the most direct thing to do is uninstall pollman.

Sure, I can disable the meters associated with pollman in
pipeline.yaml but to do I've got to go find out what they are. One
way to do that is to go look at the entry_points, but if I've got
multiple external plugins those entry_points are all over the place.
Not very friendly.

I like entry_points, especially in the way that they allow external
extensions (let's have more of them please!), but we shouldn't be
using them as service configuration[2].

What ideas do people have for being more explicit?

Now that the pollsters are only using the first half of the
pipeline.yaml file it probably makes sense to explore (in Mitaka) a more
explicit polling configuration file, separate from the transformations
described by the pipeline.

[1] https://github.com/cdent/pollman
It gets the temperature for configured locations and saves it as a
sample. Its unfinished because I promptly forgot about it until
reminded as described above.

[2] Yes, I'm conscious of the fact that this problem goes away if I
always use clean installs or virtualenvs but is that something we
always want to require? It would be handy to be able to have a
generic vm image which is "the ceilometer polling machine" and has
all the pollsters installed but not all started by default.

-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent



More information about the OpenStack-dev mailing list