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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
