Open Stack

I'm glad to see people championing the effort to implement metering. Is
there someway to refocus the enthusiasm for solving the metering problem
into engineering a general solution in OpenStack?

I'm just going to apologize in advance, but I don't think this project is
headed in the right direction.

I believe metering should be a first class concern of OpenStack and the way
this project is starting is almost exactly backwards from what I think a
solution to metering should look like.

The last thing I want to see right now is a blessed OpenStack metering
project adding more agents, coupled to a particular db and making policy
decisions about what is quantifiable.

I think there are really three problems that need to be solved to do
metering, what data to get, getting the data and doing things with the data.

>From my perspective, a lot if not all of the data events should be coming
out of the services themselves. There is already a service that should know
when an instance gets started by what tenant. A cross cutting system for
publishing those events and a service definition for collecting them seems
like a reasonable place to start. To me that should look awful lot like a
message queue or centralized logging. Once the first two problems are
solved well, if you are so inclined to collect the data into a relational
model, the schema will be obvious.

If the first two problems are solved well, then I could be persuaded that a
service that provides some of the aggregation functionality is a great idea
and a reference implementation on a relational database isn't the worst
thing in the world.

Without a general solution for the first two problems, I believe the
primary focus on a schema and db is premature and sub-optimal. I also
believe the current approach likely results in a project that is generally
unusable.

Does anyone else share my perspective?

Maybe I'm the crazy one...

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120501/8c0dcf84/attachment.html>