openstack team mailing list archive

[Zhongyue Luo <lzyeval@xxxxxxxxx>]

+1

On Wed, May 2, 2012 at 6:28 AM, Loic Dachary <loic@xxxxxxxxxxxx> wrote:

> On 05/01/2012 09:57 PM, Andrew Clay Shafer wrote:
> > 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?
> It would be better if all OpenStack core components agreed on unified
> interfaces / messages for metering that would be easy to harvest without
> installing agents on nodes. This is also true for many services outside of
> the OpenStack eco-system. However, much in the same way munin and nagios
> plugins are developped outside of the project for which they provide
> graphing and monitoring (for instance we recently published swift munin
> plugins in the repository where ops usually look for them :
> https://github.com/munin-monitoring/contrib/tree/master/plugins/swift and
> there is no glance plugin or up-to-date nova plugins yet ), metering agents
> will be developed separately, most of the time.
>
> As I wrote in a previous mail, once we manage to provide an implementation
> that proves useful, we will be in a position to approach the core OpenStack
> components. Integrating the metering agents as part of the core component,
> much in the same way it's currently done in nova. That will reduce the
> overall complexity of deploying OpenStack with metering (which must not be
> mandatory). However, there is very little chance that all components
> developed around OpenStack are convinced and there will always be a need
> for a metering that is external to the component. Therefore, even if
> metering eventually manages to become a first class concern for the core
> OpenStack components, the proposed architecture of the metering project (
> per node agents when necessary and a collector harvesting them into a
> storage ) will keep being used for other components.
>
> Do you think I'm wrong ? We're at a very early stage and now is the time
> to question everything :-)
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>