Open Stack

Hey y'all,

I've had a little thorn in my claw on this topic for a while and thought
I'd ask the larger group.

I applaud the efforts of the people working on the alarming additions to
Ceilometer, but I've got concerns that we're packaging things the wrong way.

I fear we're making another Zenoss/Nagios with Ceilometer. It's trying
to do too much.

The current trend in the monitoring work (#monitoringlove) is to build
your own stack from a series of components. These components take in
inputs, process them and spit out outputs.
Collectors/Transformers/Publishers. This is the model CM is built on.

Making an all-singing-all-dancing monolithic monitoring package is the
old way of building these tools. People want to use best-of-breed
components for their monitoring stack. I'd like to be able to use
reimann.io for my stream manager, diamond for my collector, logstash for
my parser, etc. Alarming should just be another consumer.

CM should do one thing well. Collect data from openstack, store and
process them, and make them available to other systems via the API or
publishers. That's all. It should understand these events better than
any other product out there. It should be able to produce meaningful
metrics/meters from these events.

Alarming should be yet another consumer of the data CM produces. Done
right, the If-This-Then-That nature of the alarming tool could be
re-used by the orchestration team or perhaps even scheduling.
Intertwining it with CM is making the whole thing too complex and rigid
(imho).

CM should be focused on extending our publishers and input plug-ins.

I'd like to propose that alarming becomes its own project outside of
Ceilometer. Or, at the very least, its own package, external of the
Ceilometer code base. Perhaps it still lives under the CM moniker, but
packaging-wise, I think it should live as a separate code base.

Please, change my view. :)

-S

Side note: I might even argue that the statistical features of CM are
going a little too far. My only counter-argument is that statistics are
the only way to prevent us from sending large amounts of data over the
wire for post-processing. But that's a separate discussion.