Open Stack

Excerpts from John Dickinson's message of 2014-05-04 12:37:55 -0700:
> One of the advantages of the program concept within OpenStack is that separate code projects with complementary goals can be managed under the same program without needing to be the same codebase. The most obvious example across every program are the "server" and "client" projects under most programs.
> 
> This may be something that can be used here, if it doesn't make sense to extend the ceilometer codebase itself.
> 

Totally agree. Programs can also just do targetted work in projects that
are also managed by another program. For instance, in the Deployment
program, we drive features into all of the other projects that make it
possible to deploy OpenStack with itself.

Having an API to define monitoring would be a fantastically useful thing
for that effort btw.

But I digress, I thin John is spot on here. The Telemetry program would
be the place to manage the service. However, I think it makes sense for
it to at least start out as separate from Ceilometer for one reason:
Ceilometer is focused on measuring the infrastructure itself. What is
needed is a thing for monitoring the workloads from the user POV.

They may share data model, and even API, but I imagine the backend
might be quite different, since the ceilometer agents are trusted as
being "under" the cloud and have access to RPC, but the users would be
constrained to REST API.

So sort of like Trove is eventually going to converge on using Heat, so
should a monitoring as a service project eventually converge on riding
on Ceilometer as much as possible. That said, if there's something
working now, I say bring it into the fold and iterate as needed.