Open Stack

Excerpts from Chris Dent's message of 2015-09-11 11:31:07 +0100:
> 
> 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.

How about making a tool to discover them? Something like
https://pypi.python.org/pypi/entry_point_inspector but more specific to
ceilometer plugins.

> 
> 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?

Are the plugins grouped in any way or named to allow wildcards for
partial names? For example, is it easy to say "I want all of the
compute pollsters, but I don't know their names" by using putting
something like 'compute:*' in the configuration file?

> 
> 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.

That may make sense.

> 
> [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.

I think the decision was based on the idea that we didn't expect real
deployments to install packages they weren't using. A dev environment is
obviously a different case.

Doug